No, templates are only needed to introduce new symbols. And D templates are vastly superior to C++. D's superpowers are CTFE, static if, and static foreach.
auto is used as a return type because it's easy, and in some cases because the type is defined internally in the function and can't be named.
You would not like the code that uses auto everywhere if you had to type everything out, think range wrappers that are 5 levels deep.
FOSS: DMD was always open source, but the backend license was not compatible with FOSS until about 2017. D is now officially part of GCC (as of v6 I think?), and even the frontend for D in gcc is written in D (and actively maintained).
D1 vs. D2: D2 introduced immutability and vastly superior metaprogramming system. But had incompatibilities with D1. Companies like sociomantic that standardized on D1 were left with a hard problem to solve.
Tango vs phobos: This was a case of an alternative standard library with an alternative runtime. Programs that wanted to use tango and phobos-based libraries could not. This is what prompted druntime, which is tango's runtime split out and made compatible, adopted by D2. Unforutuntately, tango took a long time to port to D2 and the maintainers went elsewhere.
gc vs. nogc: The language sometimes adds calls to the gc without obvious invokations of it (e.g. allocating a closure or setting the length of an array). You can write code with @nogc as a function attribute, and it will ban all uses of the gc, even compiler-generated ones. This severely limits the runtime features you can use, so it makes the language a lot more difficult to work with. But some people insist on it because it helps avoid any GC pauses when you can't take it. There are those who think the whole std lib should be nogc, to maximize utility, but we are not going in that direction.
Thank you for this post. I can tell you that we do appreciate comments like this, and the deficiencies you cite are many of the reasons we are rewriting phobos and druntime.
The time module "lied" seems like a straight up bug. Can you give any more details on it?
But that's only the reference compiler, DMD. The other two compilers were fully open source (including gcc, which includes D) before that.
Fully disagree on your position that having all possibilities with one language is bad. When you have a nice language, it's nice to write with it for all things.
`a` is a parameter in the lambda function `a => a.idup`.
> Why "map!"
This is definitely something that can trip up new users or casual users. D does not use <> for template/generic instantiation, we use !. So `map!(a => a.idup)` means, instantiate the map template with this lambda.
What map is doing is transforming each element of a range into something else using a transformation function (this should be familiar I think?)
FWIW, I've been using D for nearly 20 years, and the template instantiation syntax is one of those things that is so much better, but you have to experience it to understand.
> "idup" seems arbitrary
Yes, but a lot of things are arbitrary in any language.
This name is a product of legacy. The original D incarnation (called D1) did not have immutable data as a language feature. To duplicate an array, you used the property `dup`, which I think is pretty well understood.
So when D2 came along, and you might want to duplicate an array into an immutable array, we got `idup`.
Yes, you have to read some documentation, not everything can be immediately obvious. There are a lot of obvious parts of D, and I think the learning curve is low.
The rationale is that in a correctly written program, an Error should never be thrown. It's similar to UB in C. The compiler can assume Errors are never thrown, and so it can not worry about cleanup in nothrow functions.
But the nice thing is, it reuses the same handling mechanisms as exceptions. You don't have to create something different for handling Errors. In fact, the code that prints error stack traces and exits is the same code that handles exceptions.
Consequently, this is why you shouldn't catch them, or at least not catch them and continue. The exceptions are unittests and contract asserts, where the compiler does guarantee proper stack unwinding.
Oof, seems I got the camelcase wrong. It's `@mustuse`
Working on updating that.
I think the reason the documentation is cryptic is because it's a library-supplied User Data Attribute that is specially recognized by the compiler. The documentation generator is having trouble with it. In code it's pretty simple:
You can use arrays as if they were individual operands, and it will expand out the loop and apply the expression to all the values (and can use optimization/vector tricks if posssible).
e.g.:
arr1[] += arr2[] / 10.0 + 5;
TBH, I don't use this feature much, because I work with ranges more than arrays, which do not have this ability. This feature predates ranges (and the std.algorithm.map function, which can do what you say as well).