Editions: What about Compiler Plugins?

[libxmoc]

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

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

Swift, Scala, OCcaml..

It looks like there is something worth exploring here.