• libxmoc (19/19) Mar 11 The recent discussions around D Editions and Walter's call to
• libxmoc (8/29) Mar 11 Languages embracing compiler plugins:
• user1234 (5/13) Mar 12 Maybe, but you need a stable API for a plugin system (assuming
• Dennis (5/8) Mar 11 There has been work on making DMD work as a library, and some
• Stefan Koch (9/14) Mar 11 I highly doubt that it gets any simpler by factoring language
• matheus (12/13) Mar 11 Question from a layman, couldn't this create a some bottleneck on

libxmoc <libxmoc gmail.com> writes:

The recent discussions around D Editions and Walter's call to 
drop legacy features (like -revert=intpromote, complex numbers, 
or even lazy and alias this (i like alias this `:'(`)) highlight 
a recurring problem: the D compiler does too much stuff.

Simultaneously, we have ongoing debates about half implemented 
concepts like  live. As Rikki and Timon's recent exchange pointed 
out, D is stuck in a weird middle ground. It is trying to 
hardcode highly complex, paradigm-shifting semantics (like Rust 
inspired borrow checking) directly into the core compiler 
frontend, which results in confusion, incomplete implementations, 
and ever growing   soup.

Instead of just treating Editions as a garbage collection (pun 
intended) pass for old features, has anyone on the team explored 
opening up the compiler with a Plugin API?

If the AST and semantic analysis phases were exposed via a stable 
API, we could change how D evolves. Rather than bloating DMD, 
arguing over which features deserve to exist and which deserve 
the die, we could strip the core language down to a minimalist 
base for the next Edition and offload the rest to the community.

libxmoc <libxmoc gmail.com> writes:

On Wednesday, 11 March 2026 at 10:12:53 UTC, libxmoc wrote:
 The recent discussions around D Editions and Walter's call to 
 drop legacy features (like -revert=intpromote, complex numbers, 
 or even lazy and alias this (i like alias this `:'(`)) 
 highlight a recurring problem: the D compiler does too much 
 stuff.

 Simultaneously, we have ongoing debates about half implemented 
 concepts like  live. As Rikki and Timon's recent exchange 
 pointed out, D is stuck in a weird middle ground. It is trying 
 to hardcode highly complex, paradigm-shifting semantics (like 
 Rust inspired borrow checking) directly into the core compiler 
 frontend, which results in confusion, incomplete 
 implementations, and ever growing   soup.

 Instead of just treating Editions as a garbage collection (pun 
 intended) pass for old features, has anyone on the team 
 explored opening up the compiler with a Plugin API?

 If the AST and semantic analysis phases were exposed via a 
 stable API, we could change how D evolves. Rather than bloating 
 DMD, arguing over which features deserve to exist and which 
 deserve the die, we could strip the core language down to a 
 minimalist base for the next Edition and offload the rest to 
 the community.

Languages embracing compiler plugins:

Kotlin: https://kotlinlang.org/docs/compiler-plugins-overview.html

Rust: 
https://dev-doc.rust-lang.org/beta/unstable-book/language-features/plugin.html

https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/

Swift, Scala, OCcaml..

It looks like there is something worth exploring here.

user1234 <user1234 12.de> writes:

On Wednesday, 11 March 2026 at 11:48:01 UTC, libxmoc wrote:
 Languages embracing compiler plugins:

 Kotlin: 
 https://kotlinlang.org/docs/compiler-plugins-overview.html

 Rust: 
 https://dev-doc.rust-lang.org/beta/unstable-book/language-features/plugin.html

https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/

 Swift, Scala, OCcaml..

 It looks like there is something worth exploring here.

Maybe, but you need a stable API for a plugin system (assuming 
you're talking about *.so or *.dll, ala VST). That being said 
IIRC the LDC "vendor" had released such a system a few monthes 
ago.

Dennis <dkorpel gmail.com> writes:

On Wednesday, 11 March 2026 at 10:12:53 UTC, libxmoc wrote:
 Instead of just treating Editions as a garbage collection (pun 
 intended) pass for old features, has anyone on the team 
 explored opening up the compiler with a Plugin API?

There has been work on making DMD work as a library, and some 
people have been using it (example 
https://github.com/jacob-carlborg/dlp), but nothing major took 
off yet as far as I'm aware.

Stefan Koch <uplink.coder googlemail.com> writes:

On Wednesday, 11 March 2026 at 10:12:53 UTC, libxmoc wrote:
 The recent discussions around D Editions and Walter's call to 
 drop legacy features (like -revert=intpromote, complex numbers, 
 or even lazy and alias this (i like alias this `:'(`)) 
 highlight a recurring problem: the D compiler does too much 
 stuff.

I highly doubt that it gets any simpler by factoring language 
semantics into a group of compiler plugins, instead it would make 
it quite hard to figure which plugins work together.
We could have outcomes such as, this d package only compiles if 
certain plugins are enabled.
it would have the same effect as preview switches, maybe there is 
something else to be said though.

What do you think the pros and cons are ?

matheus <matheus gmail.com> writes:

On Wednesday, 11 March 2026 at 10:12:53 UTC, libxmoc wrote:
 ...

Question from a layman, couldn't this create a some bottleneck on 
compilation process for some people?

For example I remember the days of Libraries and the pain to 
compile something in C and trying to resolve symbols. This is 
easier nowadays, but this hooks couldn't bring the same problem 
with libraries from the past back?

Like when compiling someone's code I'd need his plugins as well 
right?

And finally about the maintenance, since D is small group 
couldn't this generate more burden to development?

Matheus.