Here in DLang Land we’re beginning the new year with a new release of the D reference compiler (DMD) and a beta release of the popular LLVM-based D compiler (LDC). D 2.095.0 is crammed full of 27 major changes and 78 fixes from 61 contributors. Following are some highlights that I expect some D programmers might find interesting, but please see the changelog for the full rundown. Those more interested in Bugzilla issue numbers can jump straight to the bugfix list
D 2.095.0
D’s support for other programming languages is important for interacting with existing codebases. C ABI compatibility has been strong from the beginning. Support for Objective-C and C++ came later. Though C++-compatibility is a bear to get right, it keeps improving with every compiler release. This release continues that trend and also enhances Objective-C support. We also see a number of QOL (quality-of-life) improvements throughout the compiler, libraries, and tools. DUB, the D build tool and package manager that ships with the compiler (and is also available separately), especially gets a good bit of love in this release.
C++ header generation
For a little while now, DMD has included experimental support for the generation of C++ header files from D source code, via the -CH
command-line option, in order to facilitate calling D libraries from C++. For example, given the following D source file:
cpp-ex.d
extern(C++): struct A { int x; } void printA(ref A a) { import std.stdio : writeln; writeln(a); }
And the following command line:
dmd -HC cpp-ex.d
The compiler outputs the following to stdout
(-HCf
to specify a file name, and -HCd
a directory):
// Automatically generated by Digital Mars D Compiler #pragma once #include <assert.h> #include <stddef.h> #include <stdint.h> #include <math.h> #ifdef CUSTOM_D_ARRAY_TYPE #define _d_dynamicArray CUSTOM_D_ARRAY_TYPE #else /// Represents a D [] array template<typename T> struct _d_dynamicArray { size_t length; T *ptr; _d_dynamicArray() : length(0), ptr(NULL) { } _d_dynamicArray(size_t length_in, T *ptr_in) : length(length_in), ptr(ptr_in) { } T& operator[](const size_t idx) { assert(idx < length); return ptr[idx]; } const T& operator[](const size_t idx) const { assert(idx < length); return ptr[idx]; } }; #endif struct A; struct A { int32_t x; A() : x() { } }; extern void printA(A& a);
This release brings a number of fixes and improvements to this feature, as can be seen in the changelog. Note that generation of C headers is also supported via -H
, -Hf
, and -Hd
.
Default C++ standard change
Prior to this release, extern(C++)
code was guaranteed to link with C++98 binaries out of the box. This is no longer true, and you will need to pass -extern-std=c++98
on the command line to maintain that behavior. The C++11 standard is now the default.
Additionally, the compiler will now accept -extern-std=c++20
. In practice, the only effect this has at the moment is to change the compile-time value, __traits(getTargetInfo, "cppStd")
, but new types may be added in the future.
Improved Objective-C support
Objective-C compatibility is enhanced in this release with support for Objective-C protocols. This is achieved by repurposing interface
in an extern(Objective-C)
context. Additionally, the attributes @optional
and @selector
help get the job done. Read the details and see an example in the changelog.
Improved compile-time feedback
Here’s a QOL issue that really became an annoyance after a deprecation in Phobos, the standard library: when instantiating templates, deprecation messages reported the source location deep inside the library where the deprecated feature was used (e.g., template constraints) and not the user-code instantiation that triggered it. No longer. You’ll now get a template instantiation trace just as you do on errors.
Another QOL feedback issue involved the absence of errors. The compiler would silently allow multiple definitions of identical functions in the same module. The compiler will now raise an error when it encounters this situation. However, multiple declarations are allowed as long as there is at most one definition. For mangling schemes where overloading is not supported (extern(C)
, extern(Windows)
, and extern(System)
), the compiler will emit a deprecation message.
The mainSourceFile
in DUB recipes
The mainSourceFile
entry in DUB package recipes was a way to specify a source file containing a main
function that should be excluded from unit tests when invoking dub test
. However, when setting up other configurations where the file should also not be compiled, or where a different main source file was required, it was necessary to add the file to an excludedSourceFiles
entry. This is no longer the case. If a mainSourceFile
is specified in any configuration, it will automatically be excluded from other configurations.
Propagating compiler flags to dependencies
Not every existing compiler flag has a corresponding build setting for DUB recipes. The dflags
entry allows for such flags to be configured for any project. For example, -fPic
, or -preview=in
. The catch is, it does not propagate to dependencies. Now, you can explicitly specify compiler flags for dependencies by adding a dflags
parameter to any dependency entry in a dub.json
recipe. For example:
{ "name": "example", "dependencies": { "vibe-d": { "version" : "~>0.9.2", "dflags" : ["-preview=in"] } } }
Unfortunately, it appears the implementation does not work for recipes in SDLang format (dub.sdl
), so those of us who prefer that format over JSON will have to wait a bit.
LDC 1.025-beta1
This release of LDC brings the compiler up to date with the D 2.095.0 frontend, with the prebuilt packages based on LLVM v11.0.1. The biggest news in this release looks to be the new -linkonce-templates
flag. This experimental feature causes the compiler to emit template symbols into each compilation unit that references them, “with optimizer-discardable linkonce-odr linkage”. The implementation has big wins both in terms of compile times when compiling with optimizations turned on and in cutting down on a class of template-related bugs. See the beta1 release notes for the details.
Happy New Year
On behalf of the D Language Foundation, I wish you all the very best for 2021. As a community, we weren’t affected much by the global pandemic. Sure, we were forced to cancel DConf 2020, but the silver lining is that it also motivated us to finally launch DConf Online in November. We fully intend to make this an annual event alongside of, not in place of, the real-world conference (when physically possible). Other than that, it was business as usual in D Land.
At a personal level, the lives of some in our community were disrupted last year in ways large and small. Please remember that, though the primary object that brings us together is our enthusiasm for the D programming language, we are all still human beings behind our keyboards. The majority of work that gets done in our community is carried out on a volunteer basis. All of us, as the beneficiaries, must never forget that the health and well-being of everyone in our community take top priority over any work we may want or expect to see completed. We encourage everyone to keep an ear open for those who may need to borrow it, and never be afraid to communicate that need when it feels necessary. Sometimes, an open ear can make a very big difference.
Thanks to all of you for your participation in the D community, whether as a user, a contributor, or both. Stay safe, and have a very happy 2021.