One thing that really annoyed me about D is that its documentation lists basically every function with an 'auto' return type. Auto should be completely banned from documentation, it's a complete hindrance. It's the single biggest contributor to why I stopped using D for personal projects - I was so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it and looking…
Vim vs emacs, auto inference vs explicit, I don't think it will ever end. :)
Better C – A subset of D Programming Language
201–210 of 360 posts
Re: Better C – A subset of D Programming Language
#202It's interesting how this works: - enumerate everything C is doing bad. - presents fixes with a full bag of unnecessary features that no c programmer wants. I wonder why there is no "Fixed C".
What I got: some 50,000 foot pure functional typeless language with loads of magic in the compiler that you'll never be able to reason about without having written one yourself.
Re: Better C – A subset of D Programming Language
#203Earlier quoted context omitted.
C++20 almost got them. There are some Java annotation processors that rewrite the bytecode for contracts. As extra info.
Java annotations have always struck me as interesting since they fill the Lisp macros and C preprocessor niche for Java. It's another layer of complexity, but it extends the language to offer a bit more richness or layers of abstraction. I would not be surprised if a future C++ standard adds contracts officially. Boost seems to already have contracts: https://www.boost.org/doc/libs/1_67_0/libs/contract/doc/html...
On the .NET side you have Roslyn, Attributes, expression trees and on F# quotations.
While they are all a bit cumbersome to use versus what Lisp macros allow for, they already allow for quite a lot.
Yes, there is some hope that C++23 will bring them.
The more languages support DbC the better, only so can we start seeing more widespread adoption across the industry.
Re: Better C – A subset of D Programming Language
#204Earlier quoted context omitted.
In his live-stream three days ago, Andrew Kelley showed the beginnings of Zig directly generating debug-mode executables, very quickly. And that’s before incremental compilation and linking. This guy is amazing. https://www.twitch.tv/videos/602715503 [edit: at 10:20]
Ah, that's awesome! Really cool to see a new language taking compile-time so seriously.
Re: Better C – A subset of D Programming Language
#205One thing that really annoyed me about D is that its documentation lists basically every function with an 'auto' return type. Auto should be completely banned from documentation, it's a complete hindrance. It's the single biggest contributor to why I stopped using D for personal projects - I was so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it and looking…
I've felt this as well, been using D for a couple years now, and this is the kind of thing that just makes me have to context switch more than I'd like. With the current implementation of the language it's hard to avoid, and function's return type can be quite complex, so writing it down can be hard. Another reason is the (ironically) dynamic nature of a return type. E.g. auto whatDoesItReturn(int i)() { static if (i…
Re: Better C – A subset of D Programming Language
#206Earlier quoted context omitted.
Sutter made that point under Maintainability and robustness . Like Sutter's answer, this point doesn't answer the complaint. People on the anti- auto side say it seriously harms readability, as locals' types are no longer clear at a glance. They aren't asking for a list of reasons why some people favour auto , they're asking for an answer to their readability problem. Perhaps IDEs could infer types and display them a…
In IDE-friendly languages like Kotlin, you can enable showing of inferred types, e.g. https://i.stack.imgur.com/tiqjc.png
Re: Better C – A subset of D Programming Language
#207Earlier quoted context omitted.
Repeating the same over and over again doesn't make it any clearer for the ones trying to follow your line of argumentation. Seems like you had some deep exposure to Haskell, ML or Hindley-Milner in general which, when excessively consumed, detaches from reality. For one reason or the other you take this discussion serious and personal.
If something is unclear, you can ask for clarification. I repeated the statement to three people because three people repeated the same argument to me. This is how conversations work. I have very limited exposure to haskell, am not detached from reality, and am taking nothing personal. Of course the discussion is serious, why would I spend time engaging in a frivolous and meaningless discussion?
auto map(auto x) {
if constexpr(is_same) {
struct T1 { int getStuff() { return 0; } };
return T1 {};
} else {
struct T2 { void doStuff() { } };
return T2 {};
}
}Re: Better C – A subset of D Programming Language
#208One thing that really annoyed me about D is that its documentation lists basically every function with an 'auto' return type. Auto should be completely banned from documentation, it's a complete hindrance. It's the single biggest contributor to why I stopped using D for personal projects - I was so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it and looking…
I've felt this as well, been using D for a couple years now, and this is the kind of thing that just makes me have to context switch more than I'd like. With the current implementation of the language it's hard to avoid, and function's return type can be quite complex, so writing it down can be hard. Another reason is the (ironically) dynamic nature of a return type. E.g. auto whatDoesItReturn(int i)() { static if (i…
I still think the best option is let the author describe it in ddoc, as the semantic meaning can be much easier to convey that way.
Re: Better C – A subset of D Programming Language
#209Re: Better C – A subset of D Programming Language
#210Earlier quoted context omitted.
I've felt this as well, been using D for a couple years now, and this is the kind of thing that just makes me have to context switch more than I'd like. With the current implementation of the language it's hard to avoid, and function's return type can be quite complex, so writing it down can be hard. Another reason is the (ironically) dynamic nature of a return type. E.g. auto whatDoesItReturn(int i)() { static if (i…
What would be the return type of that? Does D have an Either type?
There's a wanting implementation of a sumtype in the standard library (https://dlang.org/phobos/std_variant.html#.Algebraic), and a much better one as a package: https://code.dlang.org/packages/sumtype