Welcome to This Week in D! Each week, we'll summarize what's been going on in the D community and write brief advice columns to help you get the most out of the D Programming Language.
The D Programming Language is a general purpose programming language that offers modern convenience, modeling power, and native efficiency with a familiar C-style syntax.
This Week in D has an RSS feed.
This Week in D is edited by Adam D. Ruppe. Contact me with any questions, comments, or contributions.
A flurry of small pull requests on dmd aimed to move forward the D-style refactoring. dmd has been converted from C++ to D, but still doesn't take much advantage of D's features. The changes are being done slowly to avoid regressions as the refactoring is done.
"Things that keep D from evolving?" was a thread that made it to Reddit. It hasn't gotten much attention yet, though the talk so far has been about memory management not being revolutionary and some people feel the language has already become too large.
There has also been a pull request with discussion about adding a trivial print function that adds separators between arguments. I think this is notable because it speaks to some Phobos philosophy.
Phobos is simultaneously pulled in several directions: it wants to be approachable, but it wants to be flexible. It wants to be deep and orthogonal, yet it wants to be comprehensive.
Historically, Walter's position is that Phobos shouldn't have any thin wrappers. He felt that if something can be done in just a few lines of code, then there should not be a Phobos function for it. He has warned against making it a huge bag of shallow functions.
Andrei, on the other hand, has been advocating a "batteries included" philosophy, and wants it to do more to be immediately useful to the new user... but he also wants it to be written with a high quality toward genericness and flexibility.
And, of course, the wildcard in the whole debate is that of a package manager. Dub has entered the scene and gotten a fair amount of traction in the community, but is not seen by the main players as a piece of the Phobos puzzle, but rather as a supplemental tool.
That PR comments thread is a microcosm of this old debate, and the way it ends up going may prove to be an indicator of Phobos' direction in the coming year. Andrei's eagerness to expand the library is probably a good thing, though the question of how it expands is up in the air.
See more at the announce forum.
The compiler has semi-internal names for constructors and destructors, which are normally named via the this keyword: __ctor and __dtor.
If you are trying to reference them in a context where the this keyword is not accepted, try using the __ctor or __dtor alternative names instead.
mixin template M() { this(int) {} } struct Foo { mixin M mixedin; this(string) {} // alias this = mixedin.this; fails to compile alias __ctor = mixedin.__ctor; // but this works }
BTW, if you swap the order of the constructor declaration and the alias line in that example, it will no longer compile.
l.d(7): Error: alias l.Foo.__ctor is not a constructor; identifiers starting with __ are reserved for the implementation
The leading double underscore is technically a reserved word and not supposed to be used in user code, however it is the only way to make certain things work. Use it carefully and remember there might be strange edge cases that need other workarounds, like here, defining the constructor first so the name is already in scope by the time you try to use it.
The code above uses alias to bring the mixed in constructor into the overload set, allowing both this(int) and this(string) to be used by consumer code.
To learn more about D and what's happening in D: