Author Archives: Michael Parker

DConf T-Shirts and the Human Resource Fund

I announced the Human Resource Fund back in April as part of an initiative we’re working on with companies using D in production. It was seeded by WekaIO. Now we need to see it grow.

We always have an excess of t-shirts after DConf. Often, they are given away. This year, we intentionally ordered many more than necessary. Some were given away to “Friends of D” (such as the venue staff), but the rest were intended to help us raise money.

Some of the shirts remained in London. The remainder were given to several volunteers to carry with them back home, the goal being to position them around the world so that we can minimize shipping costs. Now, we’re ready to start sending the shirts through the mail.

Help us by donating $60 to the Human Resource Fund and one of our volunteers will send you a DConf 2019 t-shirt. To take advantage of this, you have to donate through the following campaign:

Donate and get a DConf 2019 t-shirt!

The D Language Foundation will reimburse each volunteer for the shipping costs. In order to help us minimize those costs and maximize the amount we get to keep, we’ve set up a menu organized by shirt size and region, as shown in the following screenshot.

Screenshot of donation form.This campaign will help us minimize shipping costs and keep track in real time of the number of shirts remaining. Once the shirts are gone, the campaign is closed. So please, when you make your donation, help us out by selecting the region in which you live if there are still shirts available.

Those of you who have seen our Open Collective page may be aware that Gold Donors, those who make a one-time donation of $100 or more, receive a DMan t-shirt. Personal Sponsors, those who commit to an annually recurring donation of $200 or more, receive a DMan t-shirt and a guaranteed Early-Bird discount to the next DConf. We’re extending both of those packages to the Human Resource Fund campaign.

To take advantage of this, please donate through the HR Fund campaign page:

Donate to the Human Resource Fund.

After I receive notification from Flipcause of your donation, I’ll contact you to verify your shipping address and determine the size and color you’d prefer for your new DMan t-shirt.

Dman t-shirts.

Please help us grow this fund! The General Fund is also important and we still welcome donations there, but the Human Resource Fund will be our primary focus for the next few months. The sooner we reach the levels we need, the sooner we can hire people to work on important and difficult tasks in the D ecosystem.

DConf 2019 Recap

In late November of last year, Laeeth Isharc of Symmetry Investments expressed interest in hosting DConf 2019 in London. On a personal note, I had been looking for an excuse to get back to London since my brief visit at the end of the first Berlin DConf in 2016, so as my inbox filled with emails discussing possible venues, my excitement started to build. At one point, the Royal Institution was among the list of candidates.

I couldn’t make an announcement yet as nothing was certain, but I did start teasing it on Twitter and here on the blog. At our first D Language Foundation quarterly meeting on December 1, there was unanimous agreement that London was the place to be. As the days passed and it seemed to be a near certainty, I was eager to make the announcement, but near certainty is not certainty. I had to wait until Symmetry had selected a venue. That news reached my inbox on December 21. I announced it on the blog the next day.

After that, it was time to get into the details.

Planning a DConf

Past editions of DConf were organized either by hosts with employees who regularly organize conferences as part of their job descriptions, or, in the case of DConf 2018, an event planner hired by the host. This year there were no event planners and no dedicated conference organizers. It was a very different experience compared to my first peek behind the DConf curtain last year. Most of the details were hashed out in numerous emails and phone calls with Belinda Liao. Though we can thank Laeeth and Symmetry for making DConf 2019 happen, we owe a big thanks to Belinda for making it work.

I first became acquainted with Belinda–who Laeeth introduced as his “chief of staff in London”, who Symmetry’s tech team affectionately refer to as “the official nag”, and whose official title is Business Manager for Technology at Symmetry–during last year’s Symmetry Autumn of Code. Throughout the planning for DConf, she was the one doing all of the legwork. She also made sure we covered all of the bases, querying me for our requirements, pointing out anything I overlooked, and bringing new ideas.

The venue told us they would handle the live stream, but we also wanted a separate solution for recording and producing the individual talk videos. Belinda hired Stage Engage, who sent a single technician, Rowan While, to get the job done. He set up multiple cameras and sat at his primary camera in a back corner for the entirety of the three days of talks. He and his colleagues did an excellent job and three weeks after DConf the link to download the videos was sitting in my inbox. They’re all available on our YouTube channel and are accessible, along with the slides for each talk, through the DConf 2019 schedule.

During the talk submission period, Ethan Watson reached out to tell us he could submit a talk, help us in reviewing drafts of the speakers’ slides, or volunteer to be the emcee. Andrei suggested he do all three. So he did!

This year was the first time we asked the speakers to submit drafts of their slides. Last year, Andrei participated in a conference where the speakers were required to present their talks via Skype for review prior to the conference. He suggested to me at the end of DConf 2018 that we might want to consider that this year. When Ethan came onboard, he suggested instead simply reviewing drafts of the slides, which is standard procedure at the Game Developer’s Conference where he had previously presented. So we set up a deadline for the speakers to send us their drafts. Ethan reviewed them and provided feedback.

Planning the peripherals

When I first heard we might be going to London, I wanted to find some places to see other than the well-known tourist spots. On my first visit, I’d only had a day to be a tourist. This time, my wife was coming along and we were making a two-week trip out of it. So I hit YouTube to search for some video guides. That’s where I found Joolz Guides.

Julian McDonnell uses the channel to post London history walks and travel films. A filmmaker and actor, he also makes himself available for private guided walks through his web site. The idea came to me later than it should have, but in late February I contacted Julian to see if he would be available for a couple of pre-DConf walks. He doesn’t generally work with large groups, though he told me he had scheduled a pub crawl with 18 employees of a company. So we set 18 as the maximum size of a group, worked out a payment structure based on the total number of people, and I got Andrei’s approval for the foundation to cover the cost.

Around the same time, I got in touch with a pub near the venue. Finding a nightly gathering spot was a concern from the beginning. At past conferences, it was either the “official” hotel or, last year, the venue itself. There were several hotel options around the venue, many of them rather pricey. The budget hotels didn’t strike me as places where we could be holding our nightly “BeerConf”. I wanted to avoid the situation that happened in 2017 in Berlin when the hotel staff kicked us out of the lobby and relegated us to a back room. Belinda offered suggestions and I also sought advice from Russel Winder. Ultimately, I stumbled upon the Prince Arthur Pub while poking around Google Maps one night.

The pub has a second-floor space available for private hire. Getting it booked for three nights was a simple process. It also presented an opportunity for sponsorship. Ali Çehreli had been hoping to get his employer, Mercedes Benz Research and Development North America, to sponsor us in one form or another. We had been looking at potential swag, but now that we had the pub, he got approval for the company to cover the booking fee and a couple of rounds of drinks for each person who joined us each night.

Later on, Symmetry rented a different space nearby for the third night, including beer and food. So we had a cozy neighborhood pub for the first two nights of BeerConf and a more upscale bar for the third. Two different atmospheres that both allowed us all to have a good time.

The tours

The first of the two tours we booked with Julian took place two days before the conference, starting outside the Ritz at Green Park station (which, as it turns out, is right up the street from Symmetry) and ended up at the Strand near Charring Cross. The next day we met at Temple station and went through Temple (the legal district named for Temple Church, which was built by the Knights Templar) and on a winding route through the City of London.

Julian pointed out a number of sites we most likely would not have picked out on our own, giving us little nuggets of history for each. For me, some of the highlights were the building where the Beatles did their famous rooftop concert, the tailor shop that served as a front in the movie Kingsman: The Secret Service, the story of Temple Church (which we decided at the time not to go inside, but which I will visit on my next London trip to see the tomb of William Marshal), St. Etheldreda’s Church in Ely Place (dating back to the reign of Edward I), and the Charterhouse. Oh, and an interesting bit of trivia about the origin of the Japanese word for suit.

Julian is an entertaining guide and I believe everyone enjoyed the tours. If you’re ever in London with time to spare, I recommend you contact him about a private walk or a historical pub crawl.

99 City Road

The conference took place on the second floor of Inmarsat’s Old Street office building. Some of us arrived before 8:00 am on the first day and were directed by the security staff to a cozy little waiting area on the first floor. When the time came, we were guided to a side entrance and issued ID cards that would allow us access through the main entrance through Saturday.

As far as I’m aware, the conference went smoothly for just about everyone on site. There were a few hiccups along the way, most of which were noticed by few, if any, of the attendees. For example, those of us early arrivals on the first day found that the power outlets were located under trapdoors scattered throughout the room, but they were out of range of many of the seats. Before it became an issue, Belinda appeared with two of the venue staff, all bearing power strips. Belinda put out most fires before anyone smelled smoke.

Speaking of fires, we started the third day with a test of the building’s fire alarm system. It wasn’t a drill, just a test, so we didn’t have to go anywhere. All was well. Until Steven Schveighoffer got about 75% through his talk. The Stage Engage team edited it out of their recording, but in the live stream, you can see the point where Steve was interrupted by the fire alarm. This time, it was no test. We had to evacuate the building. Several folks got outside and were told to move down the street before abruptly being called back. Five minutes later, everyone filed back into the conference hall and Steve was able to finish his talk.

The venue staff encountered their own minor issue on the first day. At every DConf, we have mid-morning and mid-afternoon snacks, but the coffee is generally available all day. At 99 City Road, they’re used to events with “coffee breaks” in the mid-morning and mid-afternoon, where the coffee is set up and taken down along with the snacks. They soon learned that many DConf attendees are powered by caffeine, so they adapted and left the coffee out all day for the duration of the conference.

The food provided for our lunch each day was fantastic. Speaking for myself, it’s the best food I’ve ever had at a DConf (I did not attend the 2014 and 2015 editions, but I doubt that they compare). It was so good that I went back for seconds each day, which was possible because we had an abundance of food. If we find ourselves at this venue again, the quality of lunch is something we know we don’t have to worry about.

We did encounter one major issue this year, though it did not affect the conference attendees. A number of remote viewers on the first day encountered issues with the live stream, with some unable to see it and others having audio trouble. The venue was using Webex to handle the live stream. Sinisa Poznanovic, the venue’s A/V tech, attempted to switch to YouTube during the lunch break, but the video was oddly being flipped horizontally. He was unable to resolve the issue before the afternoon session, but he promised to stay after we left in the evening until he got it working. When we came in the next morning, the YouTube live stream was set up and working properly. I have to say it was a pleasure working with Sinisa and he has our gratitude for the great work he did throughout the conference.

The Webex issue is something none of us foresaw, but it’s possible we could have. Belinda had sent me a PDF with the links and login information several days before the conference. At the time, I was in Canterbury hanging out with a couple of old friends. I had never heard of Webex, but a cursory search on my phone showed that it’s owned by Cisco. That and the fact that it’s what the venue crew always use were enough to satisfy me, so I searched no further and went back to my vacation. In hindsight, had I dug more deeply into the search results (which I have since done), I would have learned that 64-bit Linux is not officially supported. Had I posted the login details to the forums as soon as I got them from Belinda, those with negative Webex experiences could have spoken up prior to the conference. Such red flags might have motivated us to insist on using YouTube instead.

In the future, we’ll require YouTube for all of our live streaming and, if we encounter anything new, I’ll enlist some help to do more thorough vetting in an effort to uncover potential problems.


One of the proposals that came in during the talk submission period was from Nicholas Wilson outlining an Annual General Meeting. When the selection committee met to select this year’s speakers, we decided it would not be feasible to have an AGM as part of the regular schedule. We agreed instead to hold it before the Hackathon.

Just as the DConf Hackathon isn’t the sort of event most people think of when they hear the term, we didn’t envision the AGM as the sort of meeting corporate shareholders would be familiar with. We wanted to limit it to two hours so that we would have time for people to discuss their Hackathon plans before lunch. Nicholas had the idea and put together the agenda, so he would be the moderator. Ethan and I would roam the room with mics so attendees could ask questions. Initially, we had no plans to live stream the event, but in the end, we decided to do it anyway.

The meeting began with an announcement from Andrei. For those who haven’t heard, he is stepping away from his leadership role in the D Language Foundation. He’s still involved in the D community and still manages the foundation’s finances, but for personal reasons, he can no longer devote the time and attention a leadership role requires. Átila Neves was invited to join the team and take over that role. To what I’m certain will be the benefit of the D community, he accepted. It was made possible because Laeeth, his employer, agreed to allow him to do foundation work on Symmetry time.

One of the benefits of DConf is face-to-face communication. Some of the conversations that take place lead to new ideas, collaborations, and projects, but the majority of them are lost to time and memory. In our first AGM, we have not only the benefit of face-to-face communication but also a video record. We covered a lot of ground in the meeting: DUB, DIP 1000, the PR queue, shared, @property, std.experimental, DMD as a library, the DIP process, and more. The ideas put forward are there on video so they won’t be lost. And, thanks to the note-taking skills of Johannes Loher, we have a nice list of action items to work with.

One direct result of the AGM is that I recently revised the DIP process to address some concerns that have been raised in recent times. More items will be ticked off the action list over time.

The quarterly D Language Foundation meeting

The first two quarterly meetings took place over Skype. This time, we were able to hold it face-to-face. Andrei, Walter, Ali, and I were joined on site by representatives from a handful of D shops. We had scheduled the meeting during one of the talks so that we could ensure we’d have a quiet spot for those who were participating remotely. Unfortunately, we had issues with Google Talk for one remote participant while others who were to participate via Skype were too busy to attend.

Skyping these meetings is better than nothing, but meeting face-to-face was a tremendously more efficient and enjoyable experience. We had productive discussions on several topics that garnered more participation than the Skype meetings do, where the discussions tend to be less animated. The company reps aired their issues, we talked about some future plans, and all went well. Most of the items discussed will benefit the community at large when they are finally realized, e.g. Bugzilla issues and new tooling.

I expect our quarterly meetings will become a regular sideline event at future DConfs.

Until next year…

I thoroughly enjoyed myself at DConf this year. Last year, I was too busy emceeing to have much fun. As Ethan discovered this year, there’s more to the emcee job than one might expect (and I would say he’s much more suited to it than I am). When I did it, I was worried about drinking in the evening and wanted to get in bed early each night, so I only fully participated in BeerConf the final night. This year, I had no such concerns, though I did leave early the second night to surprise my wife for dinner.

I hope that everyone at DConf 2019 enjoyed it as much as I did. I also hope that those who were unable to attend this year, especially those who have never attended a DConf, can make the trip next year no matter where in the world we end up. Just think, it’s only been a few weeks since the conference, but we should be talking about DConf 2020 in just five more months.

The countdown is on!

Revisions to the DIP Process

At the AGM that was held prior to the Hackathon at DConf 2019 in London, I announced that I would be making revisions to the DIP progress aimed at shortening the length of time required to go from the Community  Review to a final verdict. I also, in response to Joseph Rushton Wakeling’s feedback about guidance for reviewers, agreed to enhance the existing documentation to clarify what is expected of reviewers during the Community and Final Review stages and to provide guidance on how to provide a good review.

The new documentation is now live in four documents under the new docs subdirectory in the DIP repository (all of which are linked in the README). The PROCEDURE and GUIDELINES documents are still there so that existing links remain valid, but all of their content has been replaced with links to the new documentation. Please consider the new documentation to be in draft form. I have not yet subjected them to intense editing, so any corrections are welcome, as are suggestions on how to enhance them.

Anyone intending to participate in a DIP review by leaving feedback in a review thread should familiarize themselves with the DIP Reviewer Guidelines. I can’t force anyone to do so, but I do consider this mandatory. In my role as DIP manager, trying to summarize long threads that have gone off on in-depth discussions of one thing or another, reading through post after post for any sign of actual feedback, is a time-consuming (and highly annoying!) process. Henceforth, I will be deleting any posts in Community and Final review discussion threads that do not adhere to the guidelines laid out in the above document. As I declare in the document, such posts will be copied and pasted in a separate thread where off-topic discussions of the DIP may continue. It’s not my intention to stifle debate or censor anyone or in any other ray restrict discussion of the DIP–I just want to make my job, and the DIP author’s, easier. So please, for my sake and yours, read and understand the reviewer guidelines.

The content of the GUIDELINES document, which was targeted at DIP authors, has been moved (and slightly modified) into the DIP Author Guidelines. The portion of the PROCEDURE document that was aimed at DIP authors is now in The DIP Authoring Process document. All potential DIP authors should read and understand both documents before submitting a DIP. Failure to do so may result in surprises. For example, I’m going to be more proactive in closing pull requests that are submitted while a DIP is still in development and not yet in a first draft state. So please read!

Finally, the portion of the PROCEDURE document that described the different review stages is now found in the document titled The DIP Review Process. Everyone should read this. The primary difference from the previous document is that I’ve explicitly declared that Community Reviews will always begin in the first seven days of a month and Final Reviews will always begin in the third week of a month. Additionally, where I would formerly allow multiple Community Reviews to take place simultaneously, I now restrict it to one at any given time. The goal is to streamline the process and minimize the time it takes to go from Community Review to a final verdict.

As the new document outlines, the best-case scenario, in which only one round of Community Review is required and no DIPs are in active consideration of the language maintainers when another DIP finishes the Final Review, should look like this:

  • the DIP enters Community Review in the first week of Month A.
  • after Community Review, the DIP author will have four weeks to complete any required revisions.
  • in the third week of Month B, the Final Review begins.
  • after the Final Review, no revisions are required and no other DIP is under active consideration, so the DIP may immediately move into Formal Assessment.
  • the language maintainers have enough information to render a verdict on the DIP within 30 days.

So it should take between two and three months for the review process to complete. Again, this is the best-case scenario. I expect it more likely that it will typically take between four and five months, given that some DIPs will need multiple Community Review rounds and some will require revision during Formal Assessment.

As I said at the AGM, I’m always open to improving the process to the extent I can within the boundaries of the current framework. Any fundamental structural changes will need approval by Walter and Átila. If you have any suggestions to strengthen the documentation, please let me know.

Human Resources in the D Ecosystem (or Resources, Resources, Resources)

In November of last year, I announced here that we were launching a Pull Request Manager campaign. We wanted to raise $3000 in three months as compensation for Nicholas Wilson to make a dent in the pull request queues of the core D projects. The community answered the call and Nicholas got to work. It was a successful run, so we decided to go another round.

About a month remains in the second round campaign, but donations have come in at a slower pace. Still, we’re confident the community will once again help us reach the finish line so we can compensate Nicholas for his time. We intend to launch a third round at some point in the not-too-distant future, but before we do that we’ve got some different fish to fry.

The Human Resource Share

In December 2018, the first Quarterly D Language Foundation meeting was held online. It came together at the prodding of the aforementioned Nicholas Wilson. Some well-known D shops—Dunhumby (Sociomantic), Funkwerk, WekaIO, and Symmetry Investments—were invited to send representatives to join Walter, Andrei, Ali Çehreli, Nicholas, and myself in a Skype call. Given that it was the inaugural meeting, the agenda was light. We primarily wanted to hear what the companies’ biggest D issues were at the time so that we could prioritize them in the work pipeline. However, we did raise one idea that we wanted the companies to consider for our benefit.

A persistent problem in the D ecosystem is a lack of available human resources to work on the issues that don’t fall into the realm of personal or corporate interests. By that I mean that volunteers tend to contribute where they have a personal interest and contributions from the companies tend to be aimed almost exclusively at areas that have a direct benefit to their projects. The result is that a large number of issues that do not fit into either category fall by the wayside. This is only to be expected and we aren’t complaining. What we are doing is trying to determine how to direct energy toward those neglected issues without the need for raising money.

So we asked the companies to consider a form of “human resource sharing”, the idea being that each company would periodically designate one employee to spend a day on the company dime working on D ecosystem tasks that don’t necessarily have a direct impact on the company’s interests. The representatives promised to take it back to their bosses and give us an answer at the next meeting.

In the interim, I wrote up a more concrete proposal that outlined two options for approaching it: a monthly rotation where each company takes turns doing the work, and a quarterly system where each company commits to completing at least one item on the task list per quarter. I asked the companies to provide us with their preference at our second quarterly meeting in March.

At the March meeting, we invited a few more companies to join us. Given that these are either in the startup phase or aren’t using D exclusively, I’ll play it safe and keep quiet about who they are for now. Overall, the response to the Human Resource Share was positive. Unfortunately, most of the companies are already short on human resources as it is and cannot commit to our quarterly scheme. However, one company did commit to starting immediately and another committed to providing work as they can. All of them committed to helping in other ways, which includes the provision of funds (see below), and hope to have the human resources to spare in the future.

To that end, we’ve set up the ecotasks repository to house our Ecosystem Task List. The list was initially envisioned as a collection of specific tasks, e.g. specific Bugzilla issues, but that makes it more difficult for each tasked worker to decide what to do. Instead, we’ve cobbled together a set of task groups. For now, that consists primarily of links to the GitHub Issues page for different projects and a request to “close as many issues as possible”. The idea is that workers can go to an issues page and work on solving those they can squeeze into their allotted time.

We’ve put this on GitHub not just as a means of transparency, but also because we would like to invite the entire community to participate. The list is loosely sorted by priority in that items higher on the list are considered higher priority than those lower on the list, but there’s no relative priority between specific tasks. The ordering is sure to change over time.

We ask that anyone working through the list to, at the start of the work session, open an issue and leave a comment indicating which item is being worked on. For example:

I’m working on the dub registry issues right now. Specifically, I plan to tackle issues #I, #J, and #K.

Then, at the end of the work session, close the issue with a note indicating what was accomplished.

If you have a little time to spare one weekend, please consider visiting the ecotasks repository and taking on one or two issues. Even better, challenge yourself to go through it once a month and see what you can accomplish. D depends on volunteer effort to thrive. We have a lot of it already, but we always need more. This is one of many ways to make an impact even if it isn’t an enjoyable or very visible one.

The Human Resource Fund

There are some tasks in the D ecosystem that no amount of cajoling and begging will get done because they’re too complex, too time consuming, require a specific skill set to properly complete, or all of the above. When the companies offered to throw money at us in place of human resources, that led us to a new idea.

We are now running a permanent fundraising campaign specifically aimed at solving the bigger issues. The Human Resource Fund for D Ecosystem Tasks is intended to grow and grow and grow. We’re currently in talks with some of the companies about how often and how much they can contribute toward it and in what amounts. We also invite the community at large to donate to it now and again.

Recently, Andrei mentioned in the forums that we need to put together a qualified team to complete the spec and implementation of shared. That’s an example of the sort of big issue we want to use this fund to solve. Donations small and large are equally welcome. The sooner we can get a nice pile built up, the sooner we can start prioritizing issues and finding the people to solve them.

For now, we want to focus on beefing this fund up a bit so we’re going to hold off temporarily on the next Pull Request Manager campaign, but we’ll definitely come back to that again before too long. Anyway, the current campaign is still in need of your attention!

Effecting Change

Every D user has different priorities and goals, different needs and desires. A full-featured IDE is important to one person but not even worth mentioning for another. One programmer expects to see a native D GUI, another is happy with bindings to an existing C or C++ library, and yet another has no need of a GUI at all. One person contributes to a certain D project, but never to any others, while another person has a different set they contribute to, or starts their own. Somewhere in the middle are the issues that are too boring or too complex, the issues that never rise to anyone’s attention or are considered undoable for whatever reason.

In the time I’ve been following and involved with D, I’ve seen the leadership try a number of different ways to drive energy toward some of these unsolved issues. What every approach they’ve tried has had in common is that they depend on the community. When you don’t have the human resources to do the job, you need the money to hire the human resources. When you don’t have the money, you need to ask for and rely upon the charity and goodwill of others. And if there’s no one with the bandwidth to continuously push the issue, fewer people step up. When the community doesn’t step up, then either someone on the core team has to (at the expense of time taken from their normal workload) or the issue languishes.

The two initiatives I’ve described above, the Human Resource Share and the Human Resource Fund, are the latest attempts to make things happen. Again, all contributions are welcome and appreciated! I don’t want this to come off as a complaint, because that’s not what is intended at all.

This is a call to arms! We’re asking members of the community to roll up their sleeves and do the dirty work they normally wouldn’t think to do, or even would prefer not to do. We’re asking for crowdsourced effort in solving problems that will make the D ecosystem better for all of us. A few dozen people spending an hour here or a weekend there will mean more issues closed and more members of the core team can stay focused more often on the work in their purview, which is another big win.

If you can’t help us out with your time, help us out with your money! The Human Resource fund will always need boosting. So, too, the General Fund, the current PR Manager campaign, and any other campaigns we launch in the future. You can also support us when you shop at Amazon by doing so via and selecting “D Language Foundation” as your supported charity. When you buy products marked “Eligible for AmazonSmile donation” through, the foundation will receive 0.5% of the purchase price. Finally, you’ll soon be able to support D through the DLang Swag Emporium, where you’ll be able to purchase D-themed t-shirts, coffee mugs, and more.

We’re always open to ideas on how to get more things done. If you have anything you’d like to suggest, bring it to the forums for community discussion or email me directly at

Now, let’s make things happen!

Project Highlight: DPP

D was designed from the beginning to be ABI compatible with C. Translate the declarations from a C header file into a D module and you can link directly with the corresponding C library or object files. The same is true in the other direction as long as the functions in the D code are annotated with the appropriate linkage attribute. These days, it’s possible to bind with C++ and even Objective-C.

Binding with C is easy, but can sometimes be a bit tedious, particularly when done by hand. I can speak to this personally as I originally implemented the Derelict collection of bindings by hand and, though I slapped together some automation when I ported it all over to its successor project, BindBC, everything there is maintained by hand. Tools like dstep exist and can work well enough, though they come with limitations which require careful attention to and massaging of the output.

Tediousness is an enemy of productivity. That’s why several pages of discussion were generated from Átila Neves’s casual announcement a few weeks before DConf 2018 that it was now possible to #include C headers in D code.

dpp is a compiler wrapper that will parse a D source file with the .dpp extension and expand in place any #include directives it encounters, translating all of the C or C++ symbols to D, and then pass the result to a D compiler (DMD by default). Says Átila:

What motivated the project was a day at Cisco when I wanted to use D but ended up choosing C++ for the task at hand. Why? Because with C++ I could include the relevant header and be on my way, whereas with D (or any other language really) I’d have to somehow translate the header and all its transitive dependencies somehow. I tried dstep and it failed miserably. Then there’s the fact that the preprocessor is nearly always needed to properly use a C API. I wanted to remove one advantage C++ has over D, so I wrote dpp.

Here’s the example he presented in the blog post accompanying the initial announcement:

// stdlib.dpp
#include <stdio.h>
#include <stdlib.h>

void main() {
    printf("Hello world\n".ptr);

    enum numInts = 4;
    auto ints = cast(int*) malloc(int.sizeof * numInts);
    scope(exit) free(ints);

    foreach(int i; 0 .. numInts) {
        ints[i] = i;
        printf("ints[%d]: %d ".ptr, i, ints[i]);


Three months later, dpp was successfully compiling the julia.h header allowing the Julia language to be embedded in a D program. The following month, it was enabled by default on

C support is fairly solid, though not perfect.

Although preprocessor macro support is one of dpp’s key features, some macros just can’t be translated because they expand to C/C++ code fragments. I can’t parse them because they’re not actual code yet (they only make sense in context), and I can’t guess what the macro parameters are. Strings? Ints? Quoted strings? How does one programmatically determine that #define FOO(S) (S) is meant to be a C cast? Did you know that in C macros can have the same name as functions and it all works? Me neither until I got a bug report!

Push the stdlib.dpp code block from above through and read the output to see an example of translation difficulties.

The C++ story is more challenging. Átila recently wrote about one of the problems he faced. That one he managed to solve, but others remain.

dpp can’t translate C++ template specialisations on reference types because reference types don’t exist in D. I don’t know how to translate anything that depends on SFINAE because it also doesn’t exist in D.

For those not in the know, classes in D are reference types in the same way that Java classes are reference types, and function parameters annotated with ref accept arguments by reference, but when it comes to variable declarations, D has no equivalent for the C++ lvalue reference declarator, e.g. int& someRef = i;.

Despite the difficulties, Átila persists.

The holy grail is to be able to #include a C++ standard library header, but that’s so difficult that I’m currently concentrating on a much easier problem first: being able to successfully translate C++ headers from a much simpler library that happens to use standard library types (std::string, std::vector, std::map, the usual suspects). The idea there is to treat all types that dpp can’t currently handle as opaque binary blobs, focusing instead on the production library types and member functions. This sounds simple, but in practice I’ve run into issues with LLVM IR with ldc, ABI issues with dmd, mangling issues, and the most fun of all: how to create instances of C++ stdlib types in D to pass back into C++? If a function takes a reference to std::string, how do I give it one? I did find a hacky way to pass D slices to C++ functions though, so that was cool!

On the plus side, he’s found some of D’s features particularly helpful in implementing dpp, though he did say that “this is harder for me to recall since at this point I mostly take D’s advantages for granted.” The first thing that came to mind was a combination of built-in unit tests and token strings:

unittest {
        C(q{ struct Foo { int i; } }),
        D(q{ static assert(is(typeof(Foo.i) == int)); })

It’s almost self-explanatory: the first parameter to shouldCompile is C code (a header), and the second D code to be compiled after translating the C header. D’s token strings allow the editor to highlight the code inside, and the fact that C syntax is so similar to D lets me use them on C code as well!

He also found help from D’s contracts and the garbage collector.

libclang is a C library and as such has hardly any abstractions or invariant enforcement. All nodes in the AST are represented by a libclang “cursor”, which can have several “kinds”. D’s contracts allowed me to document and enforce at runtime which kind(s) of cursors a function expects, preventing bugs. Also, libclang in certain places requires the client code to manually manage memory. D’s GC makes for a wrapper API in which that is never a concern.

During development, he exposed some bugs in the DMD frontend.

I tried using sumtype in a separate branch of dpp to first convert libclang AST entities into types that are actually enforced at compile time instead of run time. Unfortunately that caused me to have to switch to compiling all code at once since sumtype behaves differently in separate compilation, triggering previously unseen frontend bugs.

For unit testing, he uses unit-threaded, a library he created to augment D’s built-in unit testing feature with advanced functionality. To achieve this, the library makes use of D’s compile-time reflection features. But dpp has a lot of unit tests.

Given the number of tests I wrote for dpp, compiling takes a very long time. This is exacerbated by -unittest, which is a known issue. Not using unit-threaded’s runner would speed up compilation, but then I’d lose all the features. It’d be better if the compile-time reflection required were made faster.

Perhaps he’ll see some joy there when Stefan Koch’s ongoing work on NewCTFE is completed.

Átila will be speaking about dpp on May 9 as part of his presentation at DConf 2019 in London. The conference runs from May 8–11, so as I write there’s still plenty of time to register. For those who can’t make it, you can watch the livestream (a link to which will be provided in the D forums each day of the conference) or see the videos of all the talks on the D Language Foundation’s YouTube channel after DConf is complete.

DConf 2019 London Programme

The DConf 2019 schedule was published on March 17th. This year we’ve got a solid mix of first-time DConf speakers and veterans. If you haven’t visited the site in a while, you’ll surely notice that it’s been redesigned. The old version was not responsive and was quite annoying to manipulate on small screens. That has been rectified. And we’ve also got a new logo appropriate for this year’s venue.

Day One – May 8th

It wouldn’t be DConf without keynotes from Walter and Andrei. Walter’s focus this year is on memory allocation strategies in D, the talk which will kick off Day 1. The video of his talk from last year was one of those we lost to a technical error, but the slides are available for download. Both slides and video are available for his talks from every previous edition: 2017 in Berlin, 2016 in Berlin, 2015 in Utah, 2014 in Menlo Park, and 2013 in Menlo Park.

First-time DConf speaker Jens Mueller follows Walter’s keynote with a talk on the approach Dunhumby (formerly Sociomantic Labs) takes for implementing machine learning. Specifically, he’ll be covering how they integrated a C library, MXNet, into their D applications.

D bug fixing machine Razvan Nitu is back this year, speaking just before lunch on Day 1. He presented half-hour talks at DConf 2017 in Berlin and 2018 in Munich related to his D Language Foundation scholarship at Politehnica University of Bucharest. This year, he’s doing a full hour on the new D Copy Constructor from the recently approved DIP 1018.

Robert Schadek has presented at DConf 2013 in Menlo Park and DConf 2016 in Berlin. This year he’s got the much-coveted post-lunch slot, where he’ll tell us all why spreadsheets must die. What’s the D connection?

After a brief and humorous look into the capabilities and idiosyncrasies of spreadsheet programming, using D as an alternative will be explored.

The next two hours are filled by three first-time DConf speakers: Guillaume Piolat will show off his intel-intrinsics library, Lionello Lunesu will give a 30-minute demonstration on packaging D applications, and prolific D contributor Sebastian Wilzbach will use a half-hour slot to explain how to become a D contributor.

Walter and Andrei will close out Day 1 with our now traditional Ask Us Anything session. They’ll take questions from the conference attendees and the livestream viewers. We’ll try to take as many as we can, but time is limited. Since it’s the last slot of the day, we don’t need to worry about fitting in a 10-minute break, so we can go the full hour, but we can’t go too far over time.

Day Two – May 9th

Our invited keynote speaker this year is Laeeth Isharc of Symmetry Investments. Laeeth has contributed to the D ecosystem in multiple ways, including setting up the 2018 Symmetry Autumn of Code and in bringing DConf to London. His abstract has not yet been published, but it will be available on his talk page once it has been.

Mathis Beer will follow Laeeth with his first DConf talk. His employer, Funkwerk, was profiled here on the D Blog in the past as part of our D in Production Series. He’ll be showing us how Funkwerk combines functional programming and OOP in their application design.

Luís Marques has occupied the pre-lunch slot on Day 1 twice: in 2016 and in 2017. Last year, he was in the post-lunch slot on Day 2. This year, he’s sending us into lunch again, this time on Day 2, with his ideas on how to make D’s compile-time features even easier to use.

Átila Neves has given some DConf lightning talks in recent years, but his last full talk was at DConf 2015, which followed his first one at DConf 2014. He’ll be giving his perspective on what motivates programming language adoption, with a look at how C++ succeeded and how D can emulate its success.

Next up are half-hour presentations from two more Politehnica University of Bucharest students. PhD candidate Eduard Staniloiu, who spoke about his work on D collections in 2017 and in 2018, will this year be telling us about the details of the upcoming ProtoObject, which is intended to become the new root of the D class hierarchy to bridge the gap between the old Object class and features that have been added to the language over time.

He’ll be followed by undergraduate Alexandru Militaru who will present the results of porting a Linux kernel driver to D to put to the test D’s suitability for systems programming and the D motto of fast code, fast.

The last full talk of the day will come from Francesco Galla, the winner of the 2018 Symmetry Autumn of Code. For the SAoC, he worked on adding HTTP/2 support to the vibe-http package. His abstract is not online at the moment, but the subject of his talk will be his SAoC project.

We end Day 2 with our traditional round of Lightning Talks. Anyone in attendance is welcome to come to the lectern and regale the crowd with a 5-minute presentation on your D-related topic of interest (sometimes, we may allow a non-D related topic if the potential presenter has a strong elevator pitch). Sign up beforehand or let us know on site. Either way, it’s first-come, first-serve. We have 10 slots available. And I have a strong suspicion that the emcee this year will ruthlessly hold speakers to their 5-minute limit!

Day Three – May 10th

The bulk of our veteran speakers are lined up on Day 3. Andrei will open this last day of talks with the final keynote of the conference. As tradition dictates, he’s keeping us in suspense as to the topic. Keep an eye on his talk page for the abstract.

At DConf 2017, Bastiaan Veelo gave a talk on using the Pegged parser generator, which we learned his company had employed to develop a transcompiler that would help them convert their Extended Pascal codebase to D. This year, he’ll be presenting a followup to that talk, detailing the challenges they’ve faced and the benefits they’ve seen from some of D’s features.

Steven Schveighoffer has become a familiar face at the DConf lectern, having presented in 2016, in 2017, and in 2018. He’s back again, this time sending us to lunch with a talk focused on generative programming, using serialization as an example of putting D’s powerful compile-time features to work in generating boilerplate code so we programmers don’t have to.

Ethan Watson, also a three-time DConf speaker (in 2016, in 2017, and in 2018),  brings us back from lunch with more compile-time desiderata. He’ll be showing how to push D’s compile-time capabilities to the limits while still keeping the code easy to maintain and highly efficient.

John Colvin has presented at DConf 2015 and DConf 2016. His talk is all about ranges; not just D ranges, but the concept of ranges, particularly as they were applied in production code at Symmetry and the lessons learned from a heavily range-based DSL.

LDC veteran and D book author Kai Nacke is another DConf three-timer: in 2016, in 2017, and in 2018. He’ll explain how his parser generator, LLTool, evolved from its conception to its current state.

Ali Çehreli is, along with Walter and Andrei, an officer of the D Language Foundation and the author of the excellent ‘Programming in D’ book, available for purchase in print and freely online. He’s also a two-time DConf speaker, in 2013 and in 2016. This year he’s bringing us an experience report on how he employed D to develop a tool in his job with Mercedes-Benz Research and Development North America.

Day 4 – May 11th – The Hackathon

The DConf Hackathon returns for its third consecutive iteration. It’s not the sort of hackathon most programmers are familiar with, where multiple teams compete to develop a program from scratch, usually over several days. Instead, it’s a single day of collaboration on D and its ecosystem.

Participants are free to work on any project they’d like or none at all. Typically, a few people sit down and catch up on the personal projects they’ve not had time for, some recruiting others to help or provide feedback. Others come together to plan new projects or to work on issues affecting the D ecosystem. Some provide impromptu tutorial sessions on D or specific programming topics. Others take the time to chat.

Each of the two previous Hackathons saw significant work accomplished, including numerous pull requests for outstanding Bugzilla issues in the core D projects and even the implementation of a new D feature (static foreach, as described in DIP 1010, was implemented at the first Hackathon at DConf 2017).

Last year, we started the Hackathon with an extra talk about WekaIO’s open source run-time support library, Mecca. This year we’re opening with an Annual General Meeting (AGM). The goal is to discuss and, hopefully, resolve some of the outstanding issues in the D Community and potentially set the stage for some work during the Hackathon.

The plan is to keep the AGM to under two hours so that we can have time for the morning Hackathon session. This will give folks a chance to get their game plans set so they can jump right into the code at the afternoon session after lunch.

The Bennies

As a reminder, we’ve got the 2nd-floor room at the Prince Arthur pub, not far from the venue, each of the first three evenings of the conference, courtesy of Mercedes-Benz Research and Development North America. We’ll have a couple of free rounds each night for all who show up.

We’ve also tentatively scheduled tours with Julian McDonnel of On May 6th and 7th, he’ll be taking those who have signed up on a walking tour from Temple Station to London Bridge. Details on how to participate are provided to all who register. Slots are limited and it’s first-come, first-serve.

The 15% Early-Bird registration discount has been extended until March 24th. Register before it goes away.

See you in London!

DMD 2.085.0 and DConf 2019 News

Coinciding with news of a new release of DMD is news about DConf 2019 in London. From new GC options in DRuntime to free beers and free tours at DConf, we may as well kill two birds with one blog post!

Compiler news

The 2.085.0 release of DMD, the D reference compiler, is now ready for download. Among other things, this release sees support for 32-bit OS X removed, more support for interfacing with Objective-C, and big news on the garbage collection front. There’s also been some work on compatibility with the standard C++ library. In total, 2.085.0 represents 58 closed Bugzilla issues and the efforts of 49 contributors. See the changelog for the full details.

Interfacing with Objective-C

DMD has had limited support for binding with Objective-C for some time. This release expands that support to include classes, instance variables, and super calls.

Previously, binding with Objective-C classes required using D interfaces. No longer. Now, Objective-C classes can be declared directly as D classes. Decorate an Objective-C class with extern(Objective-C), make use of the @selector attribute on the methods, and away you go.

To better facilitate interaction between the two languages, such classes have slightly modified behavior. Any static and final methods in an extern(Objective-C) class are virtual. However, final methods still are forbidden from being overridden by subclasses. static methods are overridable.

extern (Objective-C)
class NSObject
    static NSObject alloc() @selector("alloc");
    NSObject init() @selector("init");
    void release() @selector("release");

extern (Objective-C)
class Foo : NSObject
    override static Foo alloc() @selector("alloc");
    override Foo init() @selector("init");

    int bar(int a) @selector("bar:")
        return a;

void main()
    auto foo = Foo.alloc.init;
    scope (exit) foo.release();

    assert( == 3);

It’s also now possible to declare instance variables in Objective-C classes and for a method in an Objective-C class to make a super call.

extern (Objective-C)
class NSObject
    void release() @selector("release");

extern (Objective-C)
class Foo : NSObject
    // instance variable
    int bar;

    int foo() @selector("foo")
        return 3;

    int getBar() @selector("getBar")
        return bar;

extern (Objective-C)
class Bar : Foo
    static Bar alloc() @selector("alloc");
    Bar init() @selector("init");

    override int foo() @selector("foo")
        // super call
        return + 1;

New GC stuff

Perhaps the biggest of the GC news items is that DRuntime now ships with a precise garbage collector. This can be enabled on any executable compiled and linked against the latest DRuntime by passing the runtime option --DRT-gcopt=gc:precise. To be clear, this is not a DMD compiler option. Read the documentation on the precise GC for more info.

Another new GC configuration option controls the behavior of the GC at program termination. Currently, the GC runs a collection at termination. This is to present the opportunity to finalize any live objects still holding on to resources that might affect the system state. However, this doesn’t guarantee all objects will be finalized as roots may still exist, nor is the need for it very common, so it’s often just a waste of time. As such, a new cleanup option allows the user of a D program to specify three possible approaches to GC clean up at program termination:

  • collect: the default, current, behavior for backward compatibility
  • none: do no cleanup at all
  • finalize: unconditionally finalize all live objects

This can be passed on the command line of a program compiled and linked against DRuntime as, e.g. --DRT-gcopt=cleanup:finalize.

All DRuntime options, including the two new ones, can be set up in code rather than being passed on the command line by declaring and initializing an array of strings called rt_options. It must be both extern(C) and __gshared:

extern(C) __gshared string[] rt_options = ["gcopt=gc:precise cleanup:none"];

See the documentation on configuring the garbage collector for more GC options.

Additional GC-related enhancements include programmatic access to GC profiling statistics and a new GC registry that allows user-supplied GCs to be linked with the runtime (see the documentation for details).

Standard C++

There are two enhancements to D’s C++ interface in this release. The first is found in the new DRuntime module, core.stdcpp.new_. This provides access to the global C++ new and delete operators so that D programs can allocate from the C++ heap. The second is the new core.stdcpp.allocator module, which exposes the std::allocator<T> class of C++ as a foundation for binding to the STL container types that allocate.

DConf 2019 news

There are two interesting perks for conference goers this year.

The nightly gathering spot

We now have an “official” gathering spot. Usually at DConf, we pick an “official” hotel where the D Language Foundation folks and many attendees stay, but where a number of conference goers gather in the evenings after dinner. This year, a number of factors made it difficult to pick a reasonable spot, so we opted for something different.

There’s a cozy little pub around the corner from the venue, the Prince Arthur, that has a nice room on the second floor available for reservation. There’s a limit on how many bodies we can pack in there at once, but folks generally come and go throughout the evening anyway. Any overflow can head downstairs to the public area. We’ve got the room May 8, 9, and 10.

Additionally, we’ll be offering a couple of free rounds each night courtesy of Mercedes-Benz Research & Development North America. Free drinks in a cozy backstreet London pub sounds like a great way to pass the time!

Check out the DConf venue page for details about the Prince Arthur and how to get there.

A free tour by Joolz Guides

Julian McDonnell of Joolz Guides will be taking some DConf registrants on a guided walk May 6 and 7. If you’ve never seen his YouTube channel, we recommend it. His video guides are quirky, informative, and fun.

This is available for free to all registrants, but space is limited! When you register for DConf, you’ll receive information on how to reserve your spot. We’ve arranged to have the tours in the mid-afternoon on both days so that folks arriving in the morning will have a chance to participate. This is a walking tour that will last somewhere between 3 – 4 hours, so be sure to wear comfortable shoes.

The current plan is to start at Temple Station and end at London Bridge. We hope you join us!


The DConf submission deadline of March 10 is just around the corner. Now’s the time to send in your proposal for a talk, demo, panel or research report. See the DConf 2019 homepage for submission guidelines and selection criteria. And remember, speakers are eligible for reimbursement of travel and accommodation expenses.

The early-bird registration deadline of March 17 is fast approaching. Register now to take advantage of the 15% discount!

Project Highlight: Spasm

In 2014, Sebastiaan Koppe was working on a React project. The app’s target market included three-year-old mobile phones. He encountered some performance issues that, after investigating, he discovered weren’t attributable solely to the mobile platform.

It all became clear to me once I saw the flame graph. There were so many function calls! We managed to fix the performance issues by being a little smarter about updates and redraws, but the sight of that flame graph never quite left me. It made me wonder if things couldn’t be done more efficiently.

As time went on, Sebastiaan gained the insight that a UI is like a state machine.

Interacting with the UI moves you from one state to the next, but the total set of states and the rules governing the UI are all static. In fact, we require them to be static. Each time a user clicks a button, we want it to respond the same way. We want the same input validations to run each time a user submits a form.

So, if everything is static and defined up-front, why do all the javascript UI frameworks work so hard during runtime to figure out exactly what you want rendered? Would it not be more efficient to figure that out before you send the code to the browsers?

This led him to the idea of analyzing UI definitions to create an optimal UI renderer, but he was unable to act on it at the time. Then in 2018, native-language DOM frameworks targeting WebAsm, like asm-dom for C++ and Percy for Rust, came to his attention. Around the same time, the announcement of Vladimir Panteleev’s dscripten-tools introduced him to Sebastien Alaiwan’s older dscripten project. The former is an alternative build toolchain for the latter, which is an example of compiling D to asm.js via Emscripten. Here he saw an opportunity to revisit his old idea using D.

D’s static introspection gave me the tools to create render code at compile time, bypassing the need for a virtual DOM. The biggest challenge was to map existing UI declarations and patterns to plain D code in such a way that static introspection can be used to extract all of the information necessary for generating the rendering code.

One thing he really wanted to avoid was the need to embed React’s Javascript extension, JSX, in the D code, as that would require the creation of a compile-time parser. Instead, he decided to leverage the D compiler.

For the UI declarations, I ended up at a design where every HTML node is represented by a D struct and all the node’s attributes and properties are members of that struct. Combined with annotations, it gives enough information to generate optimal render code. With that, I implemented the famous todo-mvc application. The end result was quite satisfying. The actual source code was on par or shorter than most javascript implementations, the compiled code was only 60kB after gzip, and rendering various stages in the todo app took less than 2ms.

He announced his work on the D forums in September of 2018 (the live demo is still active as I write).

Unfortunately, he wasn’t satisfied with the amount of effort involved to get the end result. It required using the LLVM-based D compiler, LDC, to compile D to LLVM IR, then using Emscripten to produce asm.js, and finally using binaryen to compile that into WebAssembly. On top of that…

…you needed a patched version of LLVM to generate the asm.js, which required a patched LDC. Compiling all those dependencies takes a long time. Not anything I expect end users to willfully subject themselves to. They just want a compiler that’s easy to install and that just works.

As it happened, the 1.11.0 release of LDC in August 2018 actually had rudimentary support for WebAssembly baked in. Sebastiaan started rewriting the todo app and his Javascript glue code to use LDC’s new WebAssembly target. In doing so, he lost Emsripten’s bundled musl libc, so he switched his D code to use -betterC mode, which eliminates D’s dependency on DRuntime and, in turn, the C standard library.

With that, he had the easy-to-install-and-use package he wanted and was able to get the todo-mvc binary down to 5kb after gzip. When he announced this news in the D forums, he was led down a new path.

Someone asked about WebGL. That got me motivated to think about creating bindings to the APIs of the browser. That same night I did a search and found underrun, an entry in the 2018 js13k competition. I decided to port it to D and use it to figure out how to write bindings to WebGL and WebAudio.

He created the bindings by hand, but later he discovered WebIDL. After the underrun port was complete, he started work on using WebIDL to generate bindings.

It formed very quickly over the course of 2–3 months. The hardest part was mapping every feature of WebIDL to D, and at the same time figuring out how to move data, objects and callbacks between D and Javascript. All kinds of hard choices came up. Do I support undefined? Or optional types? Or union types? What about the “any” type? The answer is yes, all are supported.

He’s been happy with the result. D bindings to web APIs are included in Spasm and they follow the Javascript API as much as possible. A post-compile step is used to generate Javascript glue code.

It runs fairly quickly and generates only the Javascript glue code you actually need. It does that by collecting imported functions from the generated WebAssembly binary, cross-referencing those to functions to WebIDL definitions and then generating Javascript code for those.

The result of all this is Spasm, a library for developing single-page WebAssembly applications in D. The latest version is always available in the DUB repository.

I can’t wait to start working on hot module replacement with Spasm. Many Javascript frameworks provide it out-of-the box and it is really valuable when developing. Server-side rendering is also something that just wants to get written. While Spasm doesn’t need it so much to reduce page load times, it is necessary when you want to unittest HTML output or do SEO.

At the moment, his efforts are directed toward creating a set of basic material components. He’s had a hard time getting something together that works in plain D, and at one point considered abandoning the effort and working instead on a declarative UI language that compiles to D, but ultimately he persisted and will be announcing the project soon.

After the material project there are still plenty of challenges. The biggest thing I have been postponing is memory management. Right now the allocator in Spasm is a simple bump-the-pointer allocator. The memory for the WebAssembly instance in the browser is hardcoded to 16mb and when it’s full, it’s full. I could grow the memory of course, but I really need a way to reuse memory. Without help from the compiler – like Rust has – that either means manual memory management or a GC.

One way to solve the problem would be to port DRuntime to WebAssembly, something he says he’s considered “a few times” already.

At least the parts that I need. But so far the GC has always been an issue. In WebAssembly, memory is linear and starts at 0. When you combine that with an imprecise GC, suddenly everything looks like a pointer and, as a consequence, it won’t free any memory. Recently someone wrote a precise GC implementation. So that is definitely back on the table.

He’s also excited that he recently ran WebAssembly generated from D on Cloudflare workers.

The environment is different from a browser, but its the same in many ways. This is all very exciting and lots of possibilities will emerge for D. In part because you can generate WebAssembly binaries that are pretty lean and mean.

We’re pretty excited about the work Sebastiaan is doing and can’t wait to see where it goes. Keep an eye on the Dlang Newsfeed (@dlang_ng) on Twitter, or the official D Twitter feed (@D_Programming) to learn about future Spasm announcements.

DConf 2019 Early-Bird Registration Opens (and Other News)

I’ve got a few big news items for you today, the biggest being one I’ve been eagerly awaiting: early-bird registration for DConf 2019 London is now open!

Early-bird Registrations…

are now open!

We’re very fortunate, thanks to the generosity of Symmetry Investments, to be able to keep the normal registration fee to our standard $400 this year. Like last year, the early-bird discount is once again 15%, so register before March 17, 24:00 AOE, and you’ll only pay $340. Unfortunately, unlike past editions of DConf, we’re required to charge a VAT of 20% this year, so the early-bird rate with tax is $408 and the regular registration will be $480 with tax. The GBP value of the VAT is listed alongside the price on the registration page and will be updated when the average monthly exchange rate changes.

Currently, you’ll find two options for payment on the registration page: Flipcause and PayPal. Those of you who have been following the latest goings on will know that we’re using Flipcause to create donation campaigns. They also provide support to configure campaigns for events like DConf, allowing us to keep as much as possible coming into one place. In the long run, this will be more efficient for us than accepting money through other services, so if you aren’t paying with a PayPal balance for your DConf registration, we ask that you please choose the Flipcause option.

You’ll also find the DConf campaign listed in our Campaign Menu, which is accessible from the big Donate Now button in this blog’s sidebar as well as from the D Language Foundation’s donation page. In the past, we have supported Eventbrite as a payment option, but have not yet decided if we will do so this year.

Invited Keynote Speaker

I’m also happy to announce that Laeeth Isharc has accepted our invitation to be a keynote speaker at DConf 2019.

Every year, Walter and Andrei are joined by an invited keynote speaker to open each of the three presentation days of the conference. Sometimes, the speaker is from outside of the D community for a different perspective (Scott Meyers was the invited keynote speaker at DConfs 2014 and 2017, and Martin Odersky was the invited keynote speaker last year). This year, offering the invitation to Laeeth was a no-brainer.

Not only is Laeeth responsible for bringing DConf 2019 to London under the sponsorship of Symmetry Investments, he’s also an enthusiastic supporter of the D programming language. He hires D programmers, sponsors open-source D projects, initiated the Symmetry Autumn of Code (SAoC), and can be found in various forums around the internet answering questions about D. Despite all of that, he’s never spoken at a DConf. We can’t wait to hear what he has to say!

The SAoC Finalist

Three programmers started the Symmetry Autumn of Code. Each participant was to complete three milestones, each of one-month duration, and would receive $1000 upon the successful completion of each. After a final month of clean-up work (whatever was required by each project), one participant was to be selected for a final $1000 payment and a free pass to DConf 2019, including travel and lodging.

One participant was unable to continue after the first milestone. The other two—Francesco Mecca, whose project was porting Leandro Lucarella’s old D1 forking GC to DRuntime, and Francesco Galla, whose project was adding HTTP/2 support to vibe-http—were able to see the event through to the end. Both did some excellent work on their chosen projects, but only one would be selected for the final prize.

I can now announce that congratulations are in order for Francesco Galla! He’ll be receiving the final payment and the trip to DConf 2019. As it turns out, he and the other Francesco happen to be friends. They had an agreement beforehand that the finalist would use the extra $1000 to pay for the other to attend DConf. And we’ve been informed that we’ll be fortunate enough to meet both of them in London!

We’ll also be hearing from Francesco Mecca before then, as he has agreed to write about his project for this blog. Francesco Galla will either write a blog post or, depending on how the conference schedule comes together, give a presentation about his project at DConf (possibly both!). Keep an ear open for the announcements.

The New Fundraiser

The PR Manager Campaign was a tremendous success. Not only did we meet our goal well before the deadline, but Nicholas Wilson has done a great job cleaning up the pull request queues. We will continue that campaign for another quarter, starting next month.

In the meantime, we’re raising $2000 for a new server for the D Forums. There are two reasons we’ve selected this as our next target.

First, Vladimir Panteleev has been paying for the server for the D Forums (and his other D services) out of his pocket for years. It’s time we put a stop to that. The forums are a crucial part of the D programming language community and it shouldn’t be up to one person to pay the bills.

Second, the forums have been experiencing performance issues at an increasing frequency over the past several months. Among the possible solutions that Vladimir has identified to improve this state of things, moving to better hardware is a big one. If ever there was a time for the community to take over the server bills, it’s now.

So we encourage you to donate to the cause! Helping us meet our $2000 goal will cover a new server for the forums and provide a cushion for any incidental expenses. Vladimir has graciously declined to accept any money from the D Language Foundation for the work he does in actually maintaining and improving the forums, so we’d like to draw your attention to his Patreon account, where you can more broadly support the open-source work he does.

We thank Vladimir for all the time and money he’s put into this over the years, and thank you in advance for your donations!

DMD 2.084.0 Has Arrived

The D Language Foundation is pleased to present version 2.084.0 of DMD, the reference D compiler. It’s available for download at, where you can also find the full changelog. There are a few changes and new features to be found, as usual, along with 100 closed Bugzilla issues this time around.

Finer Control Over Run-time Checks

The new compiler flag -check is a feature that grew out of DIP 1006 and some internal discussions around its content. The flag allows overriding the default behavior of six specific categories of run-time checks by specifically turning them on or off:

  • assert – assertion checks
  • bounds – bounds checks
  • inin contracts
  • invariant – class and struct invariants
  • outout contracts
  • switch – default switch cases

For example, when compiling without -release, all run-time checks are enabled by default. To disable only assertion checks:

dmd -check=assert=off foo.d

This can be further refined with the new -checkaction flag, which determines how the program will respond when an assertion, bounds, or switch check fails. There are four options: D, C, and halt.

  • D – the default D behavior, which is to throw an Error to indicate an unrecoverable condition.
  • C – behave as a C program by calling the assertion failure function in the C runtime.
  • halt – execute a halt instruction to terminate the program.

Listed in the language documentation is a fourth option: context. This causes failed checks to throw an Error to indicate an unrecoverable condition, and also print the error context. It isn’t present in this release, but is coming in DMD 2.085 (the online documentation is generated from the DMD master branch).

Save Your Mixins

One of D’s most popular and powerful features is the mixin statement, commonly referred to as string mixins to avoid confusion with template mixins. Unfortunately, given that string mixins can be composed from multiple compile-time function calls, they are also notoriously painful to debug as they grow in complexity. The new -mixin compiler option aims to do away with that pain.

Consider the following simple (contrived) example, which attempts to generate a function call with a string mixin:

import std.stdio;

void hello() { writeln("Hello!"); }

void main() {
    mixin(hello.stringof ~ "();");

Save as hello.d, compile with dmd hello, and you’ll see an error along these lines:

hello.d-mixin-6(6): Error: function expected before (), not hello() of type void

The error does say exactly what the problem is, but even in this simple case it may require re-reading the message a few times before working out what it’s actually saying. So let’s recompile with the -mixin flag. It requires a file name. I’ve selected mixed.txt:

dmd -mixin=mixed.txt hello.d

Now we see this output:

mixed.txt(110): Error: function expected before (), not hello() of type void

See the difference? The error now refers to a line number in a file with the name we provided, rather than a line in the autogenerated hello.d-mixin-6 to which we couldn’t refer. Open mixed.txt and navigate to line 110 to find the generated code, along with a comment at line 109:

// expansion at foo.d(6)

And now the error is quite clear. Invoking .stringof on a function provides you with the function name including the parentheses, so there’s no need to append parentheses to the result. We can now change the example so that it will compile:

void main() {
    mixin(hello.stringof ~ ";");

Anyone making significant use of string mixins to generate code will undoubtedly find this feature useful. It will be particularly helpful for the maintainers of D-friendly IDEs and plugins to make the user experience more convenient.

New DUB features

DMD 2.084.0 ships with version 1.13.0 of DUB, the D build tool and package manager. It gets some new goodies with this release.

The new add command is a convenience to add dependencies to a project’s package recipe. No need to worry about the syntax and whether the recipe is written using JSON or SDLang. Simply run dub with the add command, specifying one or more dub packages, and the recipe will be modified accordingly. For example, to add the BindBC bindings for the GLFW and OpenGL C libraries:

dub add bindbc-glfw bindbc-opengl

This will add the latest version of each library. This can be restricted to a specific version by appending = to the package name along with the normal DUB syntax for version specifications. This can also be used to change the version specification of an existing dependency.

For those unfamiliar with DUB, executing dub run, or simply dub, in a directory containing a dub recipe will build a project according to the recipe and, if the project is an executable, run it once the build completes. Now, there are two new recipe directives that can be used to achieve more specialized goals. preRunCommands specifies commands to execute before the DUB target is run, and postRunCommands specifies commands to execute when the run is complete. See the DUB package recipe documentation for the JSON syntax or the SDLang syntax, under “Build Settings” in each, to see what they look like.

That’s Not All

Regarding the 100 closed Bugzilla issues, two points should be made.

First is that among many of the Pull Request merges that closed those issues, you’ll find Nicholas Wilson’s GitHub handle. Nicholas is, of course, the community member the D Language Foundation asked to serve as PR Manager, to be paid through a fundraising campaign. He’s been reviving old PRs and making sure new ones don’t go stale. This release is evidence that the initiative is paying off. And the icing on the cake is that the D community enabled us to meet our fundraising target well before our February 14th deadline. Thanks!

Second, a point relevant to the #dbugfix campaign. While I was disappointed that participation in nominating Bugzilla issues on Twitter and in the Forums dwindled to near zero, the previous nominations were not forgotten. The original goal was to fix at least two nominated issues per cycle, so several nominated bugs were never selected. However, thanks to Eduard Staniloiu and Razvan Nitu, two among that group are now closed and fixed in this release:

I’m still happy to take #dbugfix nominations. If you’ve got a Bugzilla issue that’s bugging you, tweet a link to it with #dbugfix in the text, or start a thread in the General forum with #dbugfix in the title. I’ll make a note of it and, rather than counting votes and selecting two of the top five, see if I can find someone to do something about it.