D Language Foundation April 2026 Monthly Meeting Summary

[Mike Parker]

The D Language Foundation's April 2026 monthly meeting took place 
on Friday the 17th and lasted a little under an hour.

## The Attendees

The following people attended:

* Walter Bright
* Rikki Cattermole
* Dennis Korpel
* Timon Gehr
* Mathias Lang
* Mike Parker
* Átila Neves
* Razvan Nitu
* Mario

## The Summary

### Editions

Dennis wanted to know the status of editions. Some PRs targeting 
the first edition had already been merged, even though we had 
decided that the first edition would be limited to the removal of 
deprecated features. After a brief discuission, we agreed that we 
needed to determine exactly which deprecations would become 
errors in the first edition, make sure that those already-merged 
features did not go into it, and to prevent PRs from targeting a 
future edition until they had been approved for one.

(__UPDATE__: Getting the deprecations sorted took longer than 
expected, but in the June monthly, we went through all known 
deprecations, filtered them, and came up with a list of some that 
are good to be turned into errors in the first edition, some that 
need more discussion/investigation, and some that have been 
deprecated for less than two years and so will go in a future 
edition. I'll publish some information on that shortly.)

### CTFE-only functions

Rikki said the compiler had a lot of attribute inference 
internally, including the concept of whether a function was 
available only at CTFE. The problem was that the inference 
existed, but there was no attribute tied into it.

This was holding him back in the fast DFA engine work. Some 
source code should never have code generated for it at all, and 
therefore the fast DFA engine should never need to run on it. 
Without a way to mark that kind of code as CTFE-only, there was 
no good workaround, especially in BetterC cases involving CTFE, 
memory allocation, and so on.

He said this had been requested for many years and had come up in 
more than one DIP Ideas thread. His proposal was very simple: an 
attribute, `@__ctfe`, that would set a flag. It wouldn't affect 
overloading, would not change the type system, and would not 
introduce a new overloading scheme. As far as he knew, there were 
no real downsides. He had [a PR for the 
implementation](https://github.com/dlang/dmd/pull/22557).

I remembered that we had discussed the same general issue [in a 
quarterly meeting with Ilya from 
Weka](https://forum.dlang.org/post/ljcazyvqlmvnonmhherh@forum.dlang.org). At that time, we had discussed alternatives such as `assert(__ctfe)` and a pragma. Dennis remembered that as well and said the attribute looked good to him.

Walter said he had recently sent around an email showing how D 
already had ways to require CTFE for a function without adding a 
new feature. He had discussed it with Átila, who was opposed to 
it, but Walter wanted to know what everyone else thought. He said 
that because templates were already compile-time execution 
entities, he had found two ways to cause CTFE to happen using 
features already in the language. From his perspective, we didn't 
need to invent a new pragma, keyword, or overloading mechanism.

Rikki said that what he was proposing did not involve any of 
that. It was just a small parser change that set a flag. Walter 
said that what he had read talked about overloading and other 
things and looked like it was turning into a monster, so he 
didn't know what Rikki was proposing.

Walter asked everyone to look at the two ways he had described in 
his email. He said he had been thinking about it during the 
symposium and had concluded there had to be a way to do it with 
templates. Since templates were compile-time execution entities, 
and since he had found that they could solve the problem, he 
didn't think we needed anything new.

Dennis said it wasn't really the same thing. Walter's approach 
was a template that took compile-time arguments. CTFE could also 
just be a regular integer that was incremented in a `for` loop 
and passed to a function. You couldn't instantiate a thousand 
templates in a regular `for` loop. That required a `static 
foreach`. There was a big difference between a runtime parameter 
evaluated at CTFE and a template parameter that had to be 
constant.

Walter thought the solution was for the template to call a 
function that did the loops and other work. Since the call would 
happen in a constant expression context, the function would be 
run at CTFE.

Timon said the issue, as he understood it, was that people didn't 
want functions that were only called at CTFE to end up in the 
binary. Walter said the templates wouldn't end up in the binary. 
Timon pointed out that the function called by the `consteval` 
template would end up in the binary. Walter agreed that something 
like a factorial function would be emitted, but said linkers had 
removed unreferenced functions for decades, so he didn't see the 
problem.

Timon said it was still an efficiency concern. If the compiler 
dumped many CTFE-only functions into the object file, then it 
still had to generate code for them and force the linker to 
discard them, which added build time. Walter said he didn't see 
that as a significant problem. DMD compiled very quickly even on 
his old Linux machine, and his new Mac Mini was so fast that when 
he compiled DMD, the prompt came back almost immediately. He 
didn't see code generation for some CTFE functions as a real 
problem.

I noted that it apparently was a big problem for Weka.

Átila said DMD was not that big. He also didn't want code 
generated, didn't want template symbols generated, and didn't 
want the linker to spend any more time than it already did, 
because he hated the linker with a burning passion. He said he 
wanted to use CTFE specifically because he didn't want templates. 
Templates took too long, and Symmetry had had linker issues 
because of templates in the past. Walter asked if those issues 
had been resolved. Átila didn't think so.

I clarified from the old summary that the problem hadn't been 
getting rid of functions at link time. The problem had been 
spending compiler cycles generating code for functions that would 
only be thrown away at link time.

Átila said he had run into other metaprogramming cases where he 
was forced to use templates because he didn't have this feature. 
For example, he might want to break long code into functions so 
that he could read it later. But if the code involved a string 
mixin, and he needed to pass the string to a helper function, he 
had to use a template parameter because there was no other way to 
get that string into a function that would mix it in. With 
CTFE-only functions, he could use a normal string parameter 
because the compiler would know the function was compile-time 
only.

I noted that in the previous discussion, Walter had advocated for 
`assert(__ctfe)` for the same reason he was advocating templates 
now: avoiding new language changes. But in that meeting, everyone 
had converged on an `in` contract. Walter asked if there was a 
written proposal for the contract approach.

I found [the old meeting 
summary](https://forum.dlang.org/post/ljcazyvqlmvnonmhherh@forum.dlang.org) and [the original proposal](https://forum.dlang.org/post/veqgighfeexaxrgpwnuj@forum.dlang.org). Ilya had originally proposed an attribute, which he called `@ctOnly`. In the quarterly meeting, we had discussed that attribute and alternatives such as `assert(__ctfe)` and `in(__ctfe)`. We had settled on the contract approach. No one had ever submitted a DIP for it.

Dennis looked back at the thread and said he had highlighted some 
linker problems with the contract approach and that there had 
been no response since. He said Ilya didn't want the contract 
approach because it could result in linker errors.

Rikki said he had solved the linker errors in his implementation. 
It had to be done in glue code, unfortunately, but it was 
solvable. The attribute version would produce a compiler error 
instead of a linker error because the compiler would see the 
reference to the CTFE-only function.

Dennis said the whole idea of conflating contract programming 
with this felt so wrong. Any design change regarding contract 
programming would have to keep in mind this special case we 
bolted on to it. It seemed way cleaner to keep it all separate. 
He was fine with Rikki's PR as it was.

Walter also noted a problem with inheritance. If a function were 
CTFE-only and not emitted, then an overriding function with an 
`in` contract would have trouble because the parent function 
wouldn't be there in the first place. Timon agreed that you 
couldn't widen the `in` contract in that case. Dennis said that 
was a good point, since derived classes could loosen an `in` 
contract.

Dennis said he was fine with Rikki's PR as it was. The syntax was 
already valid, it didn't add a new attribute in the sense of 
adding new surface syntax, and the compiler already had the logic 
for compile-time-only functions. The pull request just connected 
the existing syntax to the existing logic. In a perfect world, 
maybe we wouldn't need the optimization, but pragmatically, it 
seemed good enough.

Rikki then gave his objection to the `assert(__ctfe)` approach. 
If the compiler had to look for an assert somewhere in the 
function body and decide whether it had to apply the flag, it 
would have to deal with `is`, type analysis, and Boolean algebra. 
When looking at a function's parse tree, that assert could be 
multiple layers deep, requiring a nasty tree walk. With an 
attribute, the parser saw it and set the flag. That was much 
simpler and much harder to get wrong.

I suggested that the way to go would be a short DIP describing 
the attribute, the alternatives, and why the attribute was 
better. Timon said it should also explain the interactions with 
inheritance.

Dennis asked whether anyone had hard objections to the pull 
request. Átila said he didn't. Dennis said the feature had been 
bikeshedded for a long time and requested multiple times, so his 
position was to just merge it. It wasn't perfect, but it was good 
enough.

I asked whether it broke anything. It seemed completely additive. 
Dennis said it technically was additive, but we maybe could 
imagine some potential breakage. I said in that case, the 
question was whether we needed to put it in an eidtion. Átila 
didn't think so. He couldn't see how it would break anything. 
Nothing currently had the attribute. You had to add it.

Walter reviewed the PR and asked whether the attribute 
participated in or influenced overloading in any way. Rikki said 
it didn't touch the type system in any way. Walter asked whether 
it was the same as Adam Ruppe's implementation in OpenD or 
whether Rikki had reinvented it. He thought Adam had mentioned 
problems with his version and wanted to know whether those 
problems existed in Rikki's implementation. Rikki didn't remember 
anything like that. He said he hadn't handled inheritance, so 
inheritance wouldn't be taken into account.

Walter asked Rikki to compare his implementation with Adam's and 
see if anything had been missed. Timon noted that Adam's 
implementation appeared to be in semantic, while Rikki's was in 
code generation.

After reviewing the PR some more, Walter said he had no more 
objections. I said Rikki could write a DIP and we could push it 
through the process. Walter then said that the README on the PR 
was probably most of what a DIP would contain. He was thinking 
that we might not need a DIP if there were broad agreement. Átila 
and Dennis both said they thought we should just merge it. Walter 
agreed.

Walter conceded that the template explosion in his own proposal 
could be a problem. He could see the point. He thanked Rikki for 
doing the work and carrying it through.

(__UPDATE__: Rikki's PR was merged on May 8.)

### GSoC proposals and the D Programming Language Symposium

Those were the only agenda items. I asked if anyone had anything 
else.

Razvan reminded Átila that the following Tuesday was the deadline 
to submit rankings for the GSoC proposals we had received. Átila 
said he would get the ones for his project sorted by then. He 
already knew which one was his top pick.

I asked how the symposium at Yale had gone and whether the 
students there seemed interested in D. Walter said it went very 
well. Átila said the students had questions, were focused, and 
paid attention. Andrei had also shown up.

Walter said Mike Shah had done a terrific job organizing the 
event. The students who came were motivated and interested, asked 
appropriate and insightful questions, and were all extremely nice 
to him. The Yale campus was beautiful, and he had enjoyed the 
trip.

Dennis asked how Andrei was doing and whether he still used D. 
Walter said Andrei arrived that morning and Walter had to leave 
early in the afternoon, so they had very little time to talk. 
That was Walter's only disappointment. He would have liked more 
time to catch up with Andrei. Átila had talked with him a little 
longer, though he also had to return to a panel.

Walter said one piece of feedback from the symposium amused him. 
Someone had written that they hadn't known Walter really hated C. 
He was a little perturbed by that because he didn't hate C. He 
thought C had been a wonderful language forty years ago, but 
today it seemed very primitive. In his view, C was obsolete, not 
something he hated.

### DMD globals, the front end as a library, and LSP work

Rikki said Luna had asked in Discord what was holding DMD back 
from removing its extensive use of globals and making it 
instanceable.

Dennis said the short answer was a bunch of refactoring work. He 
asked if Luna's goal was making the compiler multithreaded or 
using it as a library. Rikki said she was interested in using it 
as a library and was running into problems with missing symbols 
in the front end.

Walter said removing globals was an ongoing process. He regularly 
eliminated them, but globals permeated the program and it would 
take a long time to untangle them all. He had recently been 
looking at the DWARF debug emission code, and it was heavily 
dependent on globals. That would take a while to fix.

Dennis guessed that Luna was mostly interested in the front end. 
Walter said that the lexer and parser, at least, didn't rely on 
globals. Rikki said the lexer did rely on them because of 
identifiers. Dennis said there were many cached class instances 
for basic types and common identifiers, plus other global caches. 
Walter said that if it was just a global cache for identifiers, 
he didn't see the problem. Identifiers could be shared across all 
processes and threads.

Rikki then pointed out that memory allocation itself was a 
problem. It was all meant to go through an arena, and that arena 
would have to be per compiler instance as well. Walter said that 
was a problem he hadn't thought of.

Rikki suggested that Razvan talk with Luna and see whether she 
could help do some planning for moving forward. He wasn't 
necessarily saying she should work on it, but perhaps she could 
help identify pieces of the work. Razvan said that sounded good 
and that the work could easily be bundled with the GSoC project 
for separating semantic routines.

Dennis said he had also been looking into globals because he'd 
been experimenting with a personal LSP branch for DMD. The idea 
was to make DMD support the Language Server Protocol for IDE 
integration. For that to work, DMD would need to be able to reset 
all state between runs, because a language server usually runs as 
a daemon. It could restart sometimes, but ideally it shouldn't 
need to exit just to clear compiler state. That meant either 
getting rid of globals or at least consolidating them so that all 
global state could be reset.

I asked when we had gotten an actual LSP branch for DMD. Dennis 
clarified that it was just his personal branch, not anything 
official. He had shown an early version to Robert and Walter at 
the previous DConf. He thought LSP support was a high priority 
for D.

I said I'd thought all the refactoring would have to come first. 
Dennis said removing globals was not strictly required, though it 
would make things much cleaner. Currently, the API had functions 
to initialize and deinitialize the DMD front end. Those functions 
set or reset the globals and could be called over and over again. 
That wasn't optimal, but it was probably good enough for many use 
cases.

The next step was to build prototypes and see what actually 
happened: how much memory leaked, how much work was required to 
plug the leaks, and how many easy fixes there were. DMD currently 
leaked memory intentionally, so closing enough of those leaks to 
make the front end usable as a long-running service would be 
hard. But Dennis thought it was doable in the short term.

### AI-assisted contributions

Dennis said he'd been using Claude Code for various things and 
had found it very capable for certain tasks. But AI was moving 
fast, was controversial, and raised questions about how far we 
should go. He had ambitious ideas, such as giving an agent a 
larger refactoring task like eliminating globals or even trying 
to make parts of DMD multithreaded just to see how far it could 
get. But AI could also cause a lot of churn and introduce subtle 
mistakes, so he wanted to know how comfortable everyone was with 
that.

Walter said he wasn't comfortable with giant PRs. He was fine 
with using AI to help, but the work needed to come in small, 
reviewable chunks. A PR that claimed to fix all the global 
variables at once would be impossible to review.

Átila said his Yale talk had literally been about using AI agents 
to hack on D, so he was very bullish on it. He agreed with Walter 
that even if an agent could do a big task, that didn't mean the 
result should be submitted as one big PR. It had to be 
reviewable. On the question of AI introducing mistakes, he said 
the answer was to have a really solid test suite so that we could 
have confidence in the changes. That wasn't unique to AI. He 
didn't trust human code either, including his own.

Mathias said AI was a tool. If the tool made a developer more 
productive, then by all means use it, but the contributor still 
owned the code. His understanding of the Linux kernel's stance 
was similar: the person submitting the code was offering the 
code, and they were using a tool. Claude or whatever else was not 
the contributor.

Walter agreed. Blaming the AI wasn't acceptable.

Dennis said he wasn't trying to blame AI. He'd been using it in a 
reserved way, more as a starting point, and still looked deeply 
into the code himself. But he had also seen people at the other 
extreme, running multiple agents in parallel, letting them hack 
at everything, and then committing the results without looking at 
the code. He was not a fan of that. There was a whole spectrum 
between full vibe coding and very careful, slight-improvement 
modes. That was the space he wanted to explore a bit.

Walter said that sounded good.

Timon said he had seen people recommend using AI, saying you let 
the AI do its thing and then you debug what it did. In his 
experience, the other way around worked better.

Razvan said it depended on the task. For a refactoring task, you 
could have a relatively high degree of confidence, especially 
with tests. But for designing something specific that had to 
integrate into a large codebase, the code would need more careful 
auditing.

Timon said he had asked Claude to get exceptions to work in 
WebAssembly, and it had done it in about eight hours. It seemed 
to work for his use case, but he had no idea what it might have 
broken.

Rikki reminded everyone that [he had a PR 
open](https://github.com/dlang/dmd/pull/21364) to add to 
`CONTRIBUTING.md` that tools were not responsible, humans were. 
We had talked about it in a previous meeting, but the pull 
request hadn't moved forward. He asked someone to review it, make 
suggestions, or merge it if it was fine. We needed to communicate 
our stance on AI usage.

Átila said he and Andrei had been trying to convince Walter to 
get on the agent bandwagon at Yale. Andrei had recently given a 
talk in which he told the audience to stop using ChatGPT to 
generate code. When a few people reacted, he followed up by 
saying they should use agents instead.

Átila said one important thing he had learned recently was to 
have the agent ask questions instead of making assumptions. 
Otherwise, it would create a plan that made no sense. Tell it to 
create a plan to do X, but ask questions first. When he'd tried 
that, it had brought up failure scenarios he hadn't considered. 
He thought that was useful.

With refactoring, a good test suite was especially important. If 
the code still behaved the same way after the refactor, that was 
what mattered. He still reviewed the code, but he was 
increasingly relying on tests, provided the tests were actually 
testing the right thing.

As an example, he said that if you were writing a build system 
that generated Makefiles, a bad test would simply check whether 
the output files looked like what you expected. That would be 
brittle because Make itself didn't care about formatting. The 
better test would be to have Make verify the semantics. That kind 
of test design wasn't something he thought AI was capable of 
doing for you. If you had the test in place, you might not even 
care about what the code looked like.

Rikki asked whether, given that we had Andrei around again, there 
was any chance we could get NVIDIA to donate some plans to us. 
The free LLMs he had access to weren't good, and he didn't have 
the money to pay for better ones. He said NVIDIA had an open 
source portal and gave away some free support or usage, so maybe 
we could convince them to help us because we were an open source 
project.

Walter said that with Codex, as he understood it, you paid $20 a 
month and that was it. Átila and Mathias both said you absolutely 
could run out of tokens, depending on what you did. Rikki said 
the higher-tier plan was much more expensive.

Walter said he had heard of people getting huge unexpected bills 
from Claude while trying to build things using AI, and that kind 
of thing was concerning. I asked whether there were any local 
models that were good for this. The answer was basically no. 
Dennis said local models existed, but they were a whole league 
below Codex, Claude, and the other big models.

There was a bit of discussion about the hardware required to run 
good local models. Rikki asked how many of us had a bank of RTX 
5090s. I clarified that he meant NVIDIA's top-of-the-line 
consumer graphics cards. Timon noted that the professional cards 
with HBM memory were more appropriate for some applications, but 
they were well outside the comfortable price range for most 
people. I mentioned that some people were buying Mac Studios for 
this kind of work and were looking forward to the M5 because it 
was expected to be an especially strong consumer compute machine.

## Conclusion

Our next monthly meeting took place on May 8th.

If you have anything you'd like to bring to us in a monthly 
meeting, please let me know.