First Draft: Nominal Sum Types via `enum union` and `switch` Expressions

[Meta]

On Tuesday, 15 September 2026 at 13:07:30 UTC, Dennis wrote:
> On Monday, 14 September 2026 at 06:35:13 UTC, Meta wrote:
>> ## Rationale
>>
>> (...)
>>
>> Library solutions like `std.sumtype` implement tagged unions 
>> via complex template metaprogramming. However, library 
>> implementations suffer from slow compilation throughput, 
>> opaque diagnostic errors, ...
>
> Considering std.sumtype and your implementation both exist, can 
> you give comparisons showcasing improved compile times and 
> error messages?

Compile times and error messages aren't the main reason I think 
language-level sum types are useful, so I didn't include them in 
the DIP. But the error messages are significantly better and more 
accurate by simple virtue of the fact that the compiler has 
access to a lot of information that user code doesn't.

Also doing pretty much anything with a library-based sumtype 
involves a *ton* of template instantiations. You don't need hard 
numbers to conclude that a language-level implementation will 
significantly improve on compile times, memory usage, symbol 
bloat, the optimization the compiler can perform, etc.

>> ... and the inability to exploit compiler memory layout 
>> optimizations such as niche optimization.
>
> If this is core rationale, why is "Niche Optimization" not 
> implemented

It's not core rationale. I think the DIP stands on its own 
without that section. It's just an extra nice to have thing. I 
didn't implement it yet because it's not required for the feature 
to actually work, and I wanted people to be able to check out the 
branch, build the compiler, and try it for themselves if they so 
wanted.

> and why couldn't a library sumtype do Niche Optimization? I 
> feel like currently the opposite is true: library sum types are 
> free to lay out the fields however they want, while this DIP's 
> "In-Memory Layout" section bakes a strict layout scheme into 
> the language.

It's technically true that a library sumtype could do this type 
of optimization (although there are still some things the 
compiler can do that are impossible for a library type), but it's 
difficult, tedious, and to my knowledge no library solution in D 
has actually done it. The "In-Memory Layout" section in the DIP 
defines the **canonical default lowering**; it's not the be-all 
end-all.