D News Jan-Mar 2022: SAOC 2021, D 2.099.0, DConf ’22

Digital Mars D logo

The first three months of 2022 brought some major milestones:

  • Symmetry Autumn of Code 2021 came to an end on January 15, but the judges didn’t render a decision until the middle of February. And what a surprise it was!
  • The D Language Foundation announced in January that we were hiring for a vacant position sponsored by Symmetry Investments, and in February we found the person to fill it.
  • Also in February, we made a long-awaited announcement regarding DConf.
  • In early March, D 2.099.0 was released.

That’s a pretty solid start to 2022, and most of it was made possible thanks to the generous contributions of Symmetry Investments. If you’re looking for a job, Symmetry is always hiring, including D programmers!

And now on with the news.

Symmetry Autumn of Code 2021

We started SAOC 2021 with five participants, each working on projects that would be of value to the D community. Three of them were unable to make it to the end. So it came down to two: Teodor Dutu and Luís Ferreira. Teodor was working on converting DRuntime hooks to templates, and Luís on getting support for D into LLDB, the LLVM debugger.

SAOC is sponsored by Symmetry Investments. Each year, participants promise to work on their projects at least 20 hours per week across four month-long milestones. At the end of each of the first three milestones, a panel of judges evaluates their progress to decide if they pass or fail. A passing participant is awarded a $1000 payment and allowed to continue in the next milestone. A failing participant might be given a reduced payment or none at all, and removed from the event or given a warning, depending on the circumstances leading to the failure. At the end of the fourth milestone, the judges evaluate the overall progress of each participant across the entire event and select one to receive a final $1000 payment and a free trip to DConf.

For the first time in four editions of the event, the SOAC 2021 judges were unable to agree on who should receive the final rewards. It was a three-judge panel, each of whom is a veteran of every edition of SAOC: Jon Colvin, Átila Neves, and Robert Schadek. Two of them split, and the third felt there wasn’t enough to make either of the two participants stand out above the other. Teodor and Luís both did their work, wrote detailed milestone reports, and kept up with their forum updates to the same degree. So the conflicted judge took a proposal to Laeeth Isharc of Symmetry: why not award both candidates the final payment and the DConf trip?

Congratulations to Teodor and Luís on being the first dual recipients of the final SAOC reward. They have continued working on their projects, and we look forward to seeing the work they do in the future. Thanks to all of the SAOC participants, mentors, and judges, and to Symmetry Investments for sponsoring the event every year.

The New Pull Request and Issue Manager

For over a year, Razvan Nitu has been working hard at closing Bugzilla issues and merging pull requests in his role as our Pull Request and Issue Manager. His position is sponsored by Symmetry Investments, which provided funding for two such positions. Unfortunately, real-world circumstances conspired to prevent the person selected for the second position from filling it, so it remained vacant through most of 2021.

At the beginning of this year, Symmetry committed to continuing funding for both positions (as well as a different position, that of my assistant, filled by Max Haughton). In January, we put out a call for applications. In February, we announced that Dennis Korpel was selected for the job. His proven track record as a volunteer contributor to the core D repositories made him the top contender.

Dennis officially started his new job on March 1, and he hit the ground running. We’re happy to have him on board.

Tell them about it–#dbugfix

Razvan and Dennis are here to make sure the bugs are fixed and pull requests are merged. If you have an issue that’s bugging you because it’s been open for ages, or if you feel like a pull request should be getting more attention, let them know! That’s what they’re here for.

One way you can do that is by tweeting the issue number along with #dbugfix. We initiated this hashtag a while back so that D users could bring attention to specific issues, but then the hard part was finding someone with the time and inclination to fix it. Now, with both Razvan and Dennis paid to make sure issues get fixed, the hard part is a lot easier. You can also post about issues in the forums or email social@dlang.org, and I will make sure that they see it.

Razvan and Dennis have their criteria for deciding their priorities in the absence of input, but if you bring an issue or PR to their attention, they will work to resolve it as quickly as they can.

D 2.099.0

Version 2.099.0 of DMD, the reference D compiler, was released on March 6. This is a massive release, containing 20 major changes and 221 closed Bugzilla issues from 100 contributors. Some highlights from this release: D modules can be imported into C code via ImportC; D now has throw expressions; and PE/COFF output is now the default in DMD on Windows. See the changelog for the complete list.

Import modules in C source code with ImportC

ImportC is proving to be a valuable addition to D. Once all the kinks are ironed out and a solution for handling C preprocessor directives is implemented, the need for bindings to C libraries will largely disappear—you’ll be able to bring C headers, and compile C source files, directly into your D programs without any external tools.

As of D 2.099.0, you can also bring D modules directly into C files via the __import keyword.

// dsayhello.d
import core.stdc.stdio : puts;

extern(C) void helloImport() {
    puts("Hello __import!");
// dhelloimport.c
__import dsayhello;
__import core.stdc.stdio : puts;

int main(int argc, char** argv) {
    puts("Cool, eh?");
    return 0;

Compile with:

dmd dhelloimport.c dsayhello.d

You can also use it to import C modules that have been compiled via ImportC:

// csayhello.c
__import core.stdc.stdio : puts;

void helloImport() {
    puts("Hello _import!");
// chelloimport.c
__import csayhello;
__import core.stdc.stdio : puts;

int main(int argc, char** argv) {
    puts("Cool, eh?");
    return 0;

Compile with:

dmd chelloimport.c csayhello.c

The throw expression has been implemented

For all of D’s lifetime, throw has been a statement and only a statement. It couldn’t be used in expressions because expressions must have a type, and since throw doesn’t return a value, there was no suitable type. This prevented it from being used with the following syntax:

(string err) => throw new Exception(err);

And required this form instead:

(string err) { throw new Exception(err); }

DIP 1034, which introduced a bottom type to the language, provided the means to enable throw expressions: when “a throw statement is seen as an expression returning a bottom type”. As of D 2.099.0, the following code snippet compiles:

void foo(int function() f) {}

void main() {
    foo(() => throw new Exception());

PE/COFF is the default DMD output on Windows

For many years, DMD outputs object files in the OMF format on Windows. There’s a story behind this, a large part of it related to the culture of software development on Windows, but it can be summarized in two bullet points:

  • Walter Bright already had a C compiler backend that generated OMF output, a license to distribute OMF link libraries for the Win32 API, and a linker that understands OMF (OPTLINK).
  • There was no de facto system linker on Windows when he started working on D in 1999, so he could not rely on a specific linker being installed.

Reusing the compiler backend and the linker allowed Walter to distribute DMD as a compiler that worked out of the box, without the need to install any further development tools. He felt this was important for D’s early adoption. The downside was that it also restricted DMD on Windows to 32-bit. Eventually, he had to support PE/COFF and require the Microsoft linker in order to support 64-bit output, and he implemented PE/COFF 32-bit at the same time, but he was adamant that DMD continue to work out of the box for those who didn’t want to install the Microsoft Build Tools (for the linker) and Windows SDK (for the Win32 link libraries).

Eventually, OPTLINK started showing its age. Linker errors became more common as D codebases grew. There were calls to enable PE/COFF by default. Finally, someone raised the idea of shipping the LLVM linker, LLD, along with link libraries generated from the MinGW project. This would allow DMD to eventually default to PE/COFF while maintaining the out-of-the-box experience.

DMD has been shipping with LLD for several releases, and it seems enough of the kinks have been worked out that it has been ready to become the default for a while now. Nicholas Wilson finally took the step to make that happen, Walter eventually gave it his blessing, and now PE/COFF is the default DMD output on Windows.

Practically, this means that the -m32mscoff switch has been deprecated, -m32 now specifies PE/COFF, and the new switch -m32omf can be used to produce OMF output if needed (but its OMF support will eventually be dropped). The -m64 switch has always produced PE/COFF output, so has not changed.


The beta release of LDC 1.29.0 was announced on March 10. This version of the LLVM-based D compiler is based on D 2.099.0+. It includes support for LLVM 13, no longer defaults to the ld.gold linker on Linux (LLD is recommended), and includes a breaking change for the extern(D) ABI. See the full release log for details.

DConf ’22 in London

After an unexpected and unwanted hiatus, DConf is returning to the real world! Hosted once again by Symmetry Investments, we’ll be in London, Aug 1–4, 2022. We’re currently accepting submissions and early-bird registration is open.

Guest keynote speaker

Our guest speaker this year is Roberto Ierusalimschy, Associate Professor at the PUC-Rio Department of Informatics and head designer of the Lua programming language. We’re excited that he’s able to join us. Several D community members have used or are using Lua in their D projects, including the gas dynamics toolkit at the University of Queensland that its maintainers wrote about on this blog. (You can also count me in that group. I’ve used Lua in different capacities over the years, and I maintain a set of D bindings for Lua’s C API).

Roberto was the mentor who shepherded the Origins of the D Programming Language paper through the HOPL IV conference, so he already has a connection to the D community.

I don’t know yet if his talk will be related to Lua, but I’m looking forward to hearing what he has to say.


Early-bird registration is open until May 31. The base early-bird rate is $352.75 ($423.30 after applying 20% VAT), which is 15% off the general registration of $415 ($498 with 20% VAT). We offer a student discount, a discount for major open source contributors, and a hardship rate. You can register now or learn about the discounted rates at dconf.org.


At past editions of DConf, we’ve allotted talks in 50-minute blocks with 10-minute breaks in between. This year, we’re cutting that down: we’d like to keep the talks no longer than 40–45 minutes. Part of the magic of DConf is the time spent interacting face-to-face with other D enthusiasts, so it only makes sense to make as much room for that as we can while still allowing for educational and informative presentations.

If you have something related to the D programming language that you’d like to share with the world, please send in a submission. Don’t know what to talk about? Then heed Ali Çehreli, from one of his DConf Online 2020 Q & A sessions:

Coming up with an idea for a talk is as simple as the way you use D. Just look at your code, and it makes a presentation…

If you have used the D programming language, then you have material for a talk: describe your project; talk about specific problems you solved or interesting ways in which you’ve employed language features; expound on the ups and downs of your experience learning D so that others can benefit; and so on. Take a look at the DConf and DConf Online talks available on our YouTube channel for inspiration. Even if you’ve never presented at a conference, we encourage you to send us a submission! Several D community members have given their first presentation at DConf, and we are always happy to see more.

The worst that can happen when you submit a talk is that it isn’t accepted. But if it is accepted, then you’ll be entitled to reimbursement for your transportation to and from London, and your lodging for the five nights of the conference. You get to hang out with people who share your interest in D and most of your expenses are covered, with nothing to lose if your talk isn’t accepted.

Don’t let doubt or hesitation hold you back. You can find submission details at dconf.org.


DConf ’22 is taking place a nifty venue between Moorgate and Liverpool Street Stations called CodeNode. All of our talks will be in their CTRL room on the first floor, and we’ll have the basement ESC room to ourselves for mingling between talks and during lunch. They have table tennis and foosball tables, and plenty of space in which to chill.

CodeNode isn’t far from our DConf 2019 venue, so the same budget hotels we stayed at then are also within walking distance this year. You can find a list of those and several other budget hotels in the area at dconf.org.


For every edition of DConf before 2019, we designated one area hotel as the official gathering spot. Many attendees would take rooms there, and a number of us would gather in the evenings in the hotel lobby or bar to chat over drinks and snacks. In one of our Berlin editions, Ethan Watson coined the term “BeerConf” to refer to these evening meetups. In 2019, we couldn’t find a suitable hotel in which to gather, so we hired space in a pub near the venue. When DConf was canceled in 2020, a couple of community members hosted an online BeerConf to make up for the loss of the real-world version, and they’ve been hosting it every month since.

This year, since we’re back in the same part of London, we’re again looking for a space we can rent for BeerConf. We’ve got our eyes on a couple of spaces, and we’re working to secure funding. I hope to have an update on that before the end of April.

In the meantime, keep an eye on the D Announce forum for news of our monthly online version of BeerConf, and consider picking up a BeerConf shirt from our DLang Swag Emporium!

Looking ahead

We’re looking forward to the rest of 2022. One of our big goals for this year is to lay the groundwork for bringing more structure and organization to the D ecosystem. The PR/Issue managers have made a big difference and brought order to a chaotic contribution process, but we still have a long way to get to where we’d like to be.

Soon, I’ll start publishing tutorials on the foundation’s YouTube channel. These tutorials are going to cover more than just the language syntax and semantics. They’ll also dive into the tools we use as D programmers: compilers, linkers, loaders, object files, etc. These days, it’s not unsual for a programmer new to D to have gone years without ever touching a programming language that uses the same compile-link model. Questions about static linking errors, or confusion about compiler vs. linker errors, are not uncommon. These tutorials will be short and focused on specific topics, and will hopefully serve as a means for new D programmers to up their game with the tools they use.

Once I’ve uploaded the tutorials, I’ll apply for our channel to join the YouTube Partner Program so that we can start raising money from the channel. We’re eligible now, but I don’t want to apply until I’ve established a more frequent pattern of updates.

On that note, I’d like to remind you that the D Language Foundation is available to select as a charity for the Amazon Smile program. When you shop via smile.amazon.com, selecting the D Language Foundation as your preferred charity allows us to receive a small percentage of your payment. If you shop at Amazon, it’s an easy way to support the D Language Foundation. You can find browser extensions that will redirect you to smile.amazon.com every time you visit amazon.com, such as Amazon Smile Redirect, which is available for Chrome/Edge and for Firefox. (Amazon Smile charities are domain-specific, so the D Language Foundation is only available through Amazon’s .com domain).

You can also support us by shopping at the DLang Swag Emporium or donating directly via one of the options listed at dlang.org.

We can’t wait to see you in London!

2 thoughts on “D News Jan-Mar 2022: SAOC 2021, D 2.099.0, DConf ’22

  1. Marcel Kincaid

    The Background Theory section of DIP 1034 is confused. ⊥ represents the bottom type; there is no “bottom value”–the whole point of the bottom type is that it has no values. The statement “While a bool is only 1-bit with two possible values, calling foo can actually result in three possible results: {true, false, ⊥} ” is nonsensical–that’s a set consisting of two bool values and a type, which is a category mistake. The results of calling foo could be expressed as {returns true, returns false, doesn’t return}, or {returns a value of type bool, doesn’t return} … but actions aren’t values. There are only two values in type bool and thus only two values that foo can return … not returning is not a value. That the bottom type is a subtype of every type means that foo can fail to return without violating the type system, not that it can return a “bottom value” which is a clear oxymoron.

    “Note that having a bottom type in a programming language does not add the bottom value or any run-time cost associated with it.”

    Well, yes, because there’s no such thing as “the bottom value”.

    “The bottom value is a concept that exists in any Turing complete language even without a bottom type.”

    No, there’s no such thing as “the bottom value”, in Turing complete languages or elsewhere, only in the confused thinking of the author.

    “Calling assertInBounds can produce two things: {(), ⊥}”

    Again, this is wrong; it can *do* two things, return () or not return, but it can only *produce* one thing, ().

    “It can only result in a bottom value ⊥”

    No, it can’t do that because there’s no such thing. It never results in anything; it never returns any any value.

    I hope this confusion didn’t make it into the implementation anywhere.

  2. Marcel Kincaid

    “Zig has a keyword unreachable representing the bottom value with type noreturn.”

    This is inaccurate, as there is no “bottom value”. `unreachable` is an expression of type noreturn, just as assert(0) is. In fact Zig replaces `unreachable` with a panic call in debug/safe builds, and inserts nothing at all (but optimizes so there’s often nowhere to insert anything) in fast/small builds.

    “A bottom type is added to the language

    It is used as the type of any expression that is guaranteed to terminate the program. ”

    This is, of course, quite incorrect. Expressions that are guaranteed to terminate the program need not have the bottom type, and expressions with the bottom type need not be guaranteed to terminate the program–don’t forget that a major motivation for the invention of the bottom type was to account for computations that don’t terminate. Note that in Zig it’s a compile-time “unreachable code” error if control can flow from an expression of type `noreturn` to code that otherwise can’t be reached (the error message references the noreturn expression that “diverted” control flow), and at runtime there’s a panic in debug/safe builds if `unreachable` is executed, and in fast/small builds it’s undefined behavior–which might destroy all life on the planet but isn’t guaranteed to terminate the program.

    “A function that returns auto may be inferred noreturn if every code path ends in an endless loop or expression of type noreturn.”

    It would make sense where it doesn’t have semantic implications to replace the type with noreturn for *any* such function–that works since noreturn is compatible with every other type. But one must be careful about things like typeof(foo) … you don’t want to change that just because foo infinite loops or is stubbed out with an unconditional assert or throw.

    “The type noreturn has no values, so there is no init value either (or the init value is the bottom value ⊥). ”

    There is no “bottom value”. ⊥ represents the bottom *type*: https://en.wikipedia.org/wiki/Bottom_type “In type theory, a theory within mathematical logic, the bottom type is the type that has no values. It is also called the zero or empty type, and is sometimes denoted with the up tack (⊥) symbol.”

    assert(0) is an expression of type noreturn; *it doesn’t have a value*.

    “A class may not inherit from noreturn. While noreturn is a subtype of Object, defining a subtype of the bottom type is hard to reason about and adds compiler complexity. If it turns out that inheriting from noreturn makes sense in generic code, this restriction may be lifted in the future.”

    It doesn’t make sense … noreturn is a subtype of every type, but no type (other than noreturn) is a subtype of noreturn.

    Also, you should run these formal documents through spellcheck … “ommitted”, “argmuments”, “desipte”, “stratements”, “occurance”, “attepting”, “areplied”, “proivded”, “claify”,
    “all structs a.hat the .init value should be the same with or without the noreturn field” ??

    That all said, this seems like a good improvement of the language.


Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.