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.
The dlang.org team also rolled out https, as a step toward making the distribution more secure. Currently, the https option is available, but not enforced. Next steps are putting https on the forum and This Week in D, then making it the default, and digitally signing the code so systems like Mac OSX and Windows see it as a trusted publisher.
In the compiler world, dmd is working on exception handling changes. The goal is to get cross-language exceptions working. gdc and ldc already have some support for interfacing with C++ exceptions and dmd is getting it now too. The goal for dmd is to be able to actually catch a C++ std::exception to bring interoperability with C++ to the next level.
See more at the announce forum.
Andrei is working on a container library for Phobos and asked us about construction methods: do we want a factory function or static opCall?
He was convinced by the arguments for factory functions and is moving forward with them. The containers library is being written with his design by introspection idea and using his std.allocator.
Please note that a container library using std.allocator already exists, written by EMSI and open sourced. I don't know how much (if any) of their work that Andrei is using, because he wants to try the new introspection technique. However, if you need a working container library today, EMSI's code is quite good.
Earlier today, Manu brought up a point on interoperating with C++ namespaces. He's having some trouble with it. The thread is young, but since the C++ interop features are currently poorly documented and even more poorly understood, reading this thread will surely be educational for many of us. Manu's experience in using it with existing C++ codebases may lead to D language enhancements too (though it is also possible that the D idioms just need to be worked out with the existing features).
The Graillon announcement thread also got a lot of discussion. Much of it was flame throwing, though there was also some principled disagreement on the nature of real time code and what it means to use it with the GC.
The techniques used by the Graillon author, Guillaume Piolat, were to avoid anything that might trigger a GC collection in the real time thread. He used the language feature @nogc and an operating system thread, not registered with the D runtime, to ensure the work thread would never stop.
If you never call a GC allocating function, a collection cycle will never happen in D. The garbage collector does NOT run in a thread that may stop the program at random, it only runs on demand. The @nogc annotation works to ensure you never run a GC allocation in the marked function. (It does this a bit conservatively, only allowing you to call other functions annotated with it too, which is sometimes limiting since it needs to be @nogc all the way down, but it works well when you do. Guillaume was originally a skeptic of @nogc but said he found it surprisingly useful in practice.)
The other complication is if the GC collects, it pauses all threads known to the D runtime to ensure there's no race conditions during the cycle. The key there, in this case, was "known to the D runtime". If you create a thread using OS primitives and fail to register it, that thread will *not* be paused in the event of a collection cycle. It then, of course, becomes your responsibility to ensure it doesn't reference any memory the garbage collector may be actively scanning, but if carefully managed, it is possible to pull this off correctly and not stop the whole world.
Of course, he also had to be sure the rest of the code was optimized correctly for real time audio as well. No one language feature replaced programmer diligence in making a good product. Guillaume said he might write more details about his experience, but probably won't.
And, the thread many of you have been waiting to hear about... there was a very lengthy flamewar over the dub configuration file format.
dub uses either standard JSON or a somewhat obscure format called Simple Declarative Language, or SDLang, for its package definition files. The two formats encode exactly the same data and work the same way. The user simply chooses which one they prefer. SDLang is a bit leaner than JSON and also supports comments, making it the format of choice for most the vibe.d and dub team, but others, including Walter and Andrei, prefer JSON because it is a better known format. They mistakenly believed that SDLang was invented by the vibe.d team (dub is a product of vibe.d) recently, but they were corrected - the truth is SDLang already existed before vibe.d started using it (though it never became very big). vibe.d has been using it since 2013, after a community poll selected it.
Andrei stated plainly that he feels supporting SDLang was a mistake and it ought to be dropped, so everyone goes back to using JSON, and that he felt it was a waste of time to even discuss the matter. This basically kicked off a flamewar due to the tone and mistaken beliefs about the history.
To make a long thread short, the probable take-aways are dub might switch back to defaulting to json, though sdlang will probably not be removed. We need also better communication about decisions in the community to avoid these kind of after-the-fact misconceptions in the future.
To learn more about D and what's happening in D: