21–30 of 360 posts
Earlier quoted context omitted.
I'm sorry that the question is not really related to your compilers but I'm curious about your opinion on Zig?
I know nothing about Zig.
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…
Walter here - AMA!
Do you know of use of “BetterC” in real-life (i.e: for non-pet projects)? It would be interesting to hear about some real use cases.
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…
I am not sure what to make of this pattern. At least the documentation should be more explicit about these Voldemort types. Documentation has other issues as well. The standard documentation generator doesn't cope well with version statements (conditional compilation), potentially skipping docs for stuff that wouldn't be compiled into a particular build variant.
Walter here - AMA!
What's the best way for an experienced C programmer who doesn't know C++ to learn D? What's the story in terms of using existing C (or C++) code with BetterC or D in general?
I'd pick up a comprehensive book like Ali Cehreli's "Programming in D",
https://www.amazon.com/Programming-Tutorial-Reference-Ali-Ce...
and come hang out in the D forums:
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…
With highly generic functions, it's often not possible to know what they'll return without knowing what you'll call them with. Especially given that D functions like "map" and "reduce" tend to return special iterator types so that the compiler is able to smarty fuse them where possible. If D had concepts like C++20, you could probably describe them with something looking like:
template
concept __SimpleView = // exposition only
ranges::view && ranges::range &&
std::same_as, std::ranges::iterator_t> &&
std::same_as, std::ranges::sentinel_t>;
Walter here - AMA!
What's the best way for an experienced C programmer who doesn't know C++ to learn D? What's the story in terms of using existing C (or C++) code with BetterC or D in general?
You can mix and match C and D code easily in the same program, and to a lesser extent C++ code. This means a larger project can be incrementally converted to D while keeping it running and shipping.
Walter here - AMA!
* Regarding the syntax of 'lazy'. It seems to me that it would make for better readability if the lazy keyword were required at the callsite, along the lines of doStuff(lazy getValueUsingExpensiveComputation()); rather than the current syntax where it's not clear at the callsite which, if any, of the arguments are lazy. C# does something similar with ref. What's the thinking behind D's syntax?
* What's the state, and future, of precise garbage collection in D?
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…
I think it’s really interesting that as dynamically-typed languages increasingly encourage explicit type hints, statically-typed languages are recommending “almost always auto”.