{"id":1062,"date":"2017-09-01T15:08:09","date_gmt":"2017-09-01T15:08:09","guid":{"rendered":"http:\/\/dlang.org\/blog\/?p=1062"},"modified":"2021-10-08T11:08:04","modified_gmt":"2021-10-08T11:08:04","slug":"dmd-2-076-0-released","status":"publish","type":"post","link":"https:\/\/dlang.org\/blog\/2017\/09\/01\/dmd-2-076-0-released\/","title":{"rendered":"DMD 2.076.0 Released"},"content":{"rendered":"

\"\"The core D team is proud to announce that version 2.076.0 of DMD, the reference compiler for the D programming language, is ready for download<\/a>. The two biggest highlights in this release are the new static foreach<\/code> feature for improved generative and generic programming, and significantly enhanced C language integration making incremental conversion of C projects to D easy and profitable.<\/p>\n

static foreach<\/h3>\n

As part of its support for generic and generative programming, D allows for conditional compilation by way of constructs such as version<\/code> and static if<\/code> statements. These are used to choose different code paths during compilation, or to generate blocks of code in conjunction with string and template mixins. Although these features enable possibilities that continue to be discovered, the lack of a compile-time loop construct has been a steady source of inconvenience.<\/p>\n

Consider this example, where a series of constants named val0<\/code> to valN<\/code> needs to be generated based on a number N+1<\/code> specified in a configuration file. A real configuration file would require a function to parse it, but for this example, assume the file val.cfg<\/code> is defined to contain a single numerical value, such as 10<\/code>, and nothing else. Further assuming that val.cfg<\/code> is in the same directory as the valgen.d<\/code> source file, use the command line dmd -J. valgen.d<\/code> to compile.<\/p>\n

module valgen;\r\nimport std.conv : to;\r\n\r\nenum valMax = to!uint(import(\"val.cfg\"));\r\n\r\nstring genVals() \r\n{\r\n    string ret;\r\n    foreach(i; 0 .. valMax) \r\n    {\r\n        ret ~= \"enum val\" ~ to!string(i) ~ \"=\" ~ to!string(i) ~ \";\";\r\n    }\r\n    return ret;\r\n}\r\n\r\nstring genWrites() \r\n{\r\n    string ret;\r\n    foreach(i; 0 .. valMax) \r\n    {\r\n        ret ~= \"writeln(val\" ~ to!string(i) ~ \");\";\r\n    }\r\n    return ret;\r\n}\r\n\r\nmixin(genVals);\r\n\r\nvoid main() \r\n{\r\n    import std.stdio : writeln;\r\n    mixin(genWrites);\r\n}<\/pre>\n
The manifest constant valMax<\/code> is initialized by the import<\/code> expression<\/a>, which reads in a file during compilation and treats it as a string literal. Since we\u2019re dealing only with a single number in the file, we can pass the string directly to the std.conv.to<\/code> function template to convert it to a uint<\/code>. Because valMax<\/code> is an enum<\/code>, the call to to<\/code> must happen during compilation. Finally, because to<\/code> meets the criteria<\/a> for compile-time function evaluation (CTFE), the compiler hands it off to the interpreter to do so.<\/p>\n
The genVals<\/code> function exists solely to generate the declarations of the constants val0<\/code> to valN<\/code>, where N<\/code> is determined by the value of valMax<\/code>. The string mixin on line 26 forces the call to genVals<\/code> to happen during compilation, which means this function is also evaluated by the compile-time interpreter. The loop inside the function builds up a single string containing the declaration of each constant, then returns it so that it can be mixed in as several constant declarations.<\/p>\n
Similarly, the genWrites<\/code> function has the single-minded purpose of generating one writeln<\/code> call for each constant produced by genVals<\/code>. Again, each line of code is built up as a single string, and the string mixin inside the main<\/code> function forces genWrites<\/code> to be executed at compile-time so that its return value can be mixed in and compiled.<\/p>\n
Even with such a trivial example, the fact that the generation of the declarations and function calls is tucked away inside two functions is a detriment to readability. Code generation can get quite complex, and any functions created only to be executed during compilation add to that complexity. The need for iteration is not uncommon for anyone working with D\u2019s compile-time constructs, and in turn neither is the implementation of functions that exist just to provide a compile-time loop. The desire to avoid such boilerplate has put the idea of a static foreach<\/code> as a companion to static if<\/code> high on many wish lists.<\/p>\n
At DConf 2017<\/a>, Timon Gehr rolled up his sleeves during the hackathon and implemented a pull request<\/a> to add support for static foreach<\/code> to the compiler. He followed that up with a D Improvement Proposal, DIP 1010<\/a>, so that he could make it official, and the DIP met with enthusiastic approval from the language authors. With DMD 2.076, it\u2019s finally ready<\/a> for prime time.<\/p>\n
With this new feature, the above example can be rewritten as follows:<\/p>\n
module valgen2;\r\nimport std.conv : to;\r\n\r\nenum valMax = to!uint(import(\"val.cfg\"));\r\n\r\nstatic foreach(i; 0 .. valMax) \r\n{\r\n    mixin(\"enum val\" ~ to!string(i) ~ \"=\" ~ to!string(i) ~ \";\");\r\n}\r\n\r\nvoid main() \r\n{\r\n    import std.stdio : writeln;\r\n    static foreach(i; 0 .. valMax) \r\n    {\r\n        mixin(\"writeln(val\" ~ to!string(i) ~ \");\");\r\n    }\r\n}<\/pre>\n
Even such a trivial example brings a noticeable improvement in readability. Don\u2019t be surprised to see compile-time heavy D libraries (and aren\u2019t most of them?) get some major updates in the wake of this compiler release.<\/p>\n
Better C integration and interoperation<\/h3>\n
DMD\u2019s -betterC<\/code> command line switch has been around for quite a while, though it didn\u2019t really do much and it has languished from inattention while more pressing concerns were addressed. With DMD 2.076, its time has come.<\/p>\n
The idea behind the feature is to make it even easier to combine both D and C in the same program, with an emphasis on incrementally replacing C code with D code in a working project. D has been compatible with the C ABI from the beginning and, with some work to translate C headers to D modules, can directly make C API calls without going through any sort of middleman. Going the other way and incorporating D into C programs has also been possible, but not as smooth of a process.<\/p>\n
Perhaps the biggest issue has been DRuntime. There are certain D language features that depend on its presence, so any D code intended to be used in C needs to bring the runtime along and ensure that it\u2019s initialized. That, or all references to the runtime need to be excised from the D binaries before linking with the C side, something that requires more than a little effort both while writing code and while compiling it.<\/p>\n
-betterC<\/code> aims to dramatically reduce the effort required to bring D libraries into the C world and modernize C projects by partially or entirely converting them to D. DMD 2.076 makes significant progress toward that end. When -betterC<\/code> is specified on the command line, all asserts in D modules will now use the C assert handler rather than the D assert handler. And, importantly, neither DRuntime nor Phobos, the D standard library, will be automatically linked in as they normally are. This means it\u2019s no longer necessary to manually configure the build process or fix up the binaries when using -betterC<\/code>. Now, object files and libraries generated from D modules can be directly linked into a C program without any special effort. This is especially easy when using VisualD<\/a>, the D plugin for Visual Studio. Not too long ago, it gained support for mixing C and D modules in the same project. The updated -betterC<\/code> switch makes it an even more convenient feature.<\/p>\n
While the feature is now more usable, it\u2019s not yet complete. More work remains to be done in future releases to allow the use of more D features currently prohibited in betterC<\/code>. Read more about the feature in Walter Bright\u2019s article here on the D Blog, D as a Better C<\/a>.<\/p>\n
A new release schedule<\/h3>\n
This isn\u2019t a compiler or language feature, but it\u2019s a process feature worth noting. This is the first release conforming to a new release schedule. From here on out, beta releases will be announced on the 15th of every even month, such as 2017\u201310\u201315, 2017\u201312\u201315, 2018\u20132\u201315, etc. All final releases will be scheduled for the 1st of every odd month: 2017\u201311\u201301, 2018\u201301\u201301, 2018\u201303\u201301, etc. This will bring some reliability and predictability to the release schedule, and make it easier to plan milestones for enhancements, changes, and new features.<\/p>\n
Get it now!<\/h3>\n
As always, the changes, fixes, and enhancements for this release can be found in the changelog<\/a>. This specific release will always be available for download at http:\/\/downloads.dlang.org\/releases\/2.x\/2.076.0<\/a>, and the latest release plus betas and nightlies can be found at the download page<\/a> on the DLang website.<\/p>\n","protected":false},"excerpt":{"rendered":"
The core D team is proud to announce that version 2.076.0 of DMD, the reference compiler for the D programming language, is ready for download. The two biggest highlights in this release are the new static foreach feature for improved generative and generic programming, and significantly enhanced C language integration making incremental conversion of C projects to D easy and profitable.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[26,12,8,27,4],"tags":[],"_links":{"self":[{"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/posts\/1062"}],"collection":[{"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/comments?post=1062"}],"version-history":[{"count":18,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/posts\/1062\/revisions"}],"predecessor-version":[{"id":1377,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/posts\/1062\/revisions\/1377"}],"wp:attachment":[{"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/media?parent=1062"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/categories?post=1062"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/tags?post=1062"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}