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

[Meta]

On Tuesday, 15 September 2026 at 11:10:39 UTC, DanielG wrote:
> Mostly on-board with this, with some minor quibbles:
>
> - Purely aesthetic, but: why () at the end of cases, even with 
> no payload? Required for easier parsing or something?

It's to avoid ambiguity with bare type cases. If unit variants 
didn't have () at the end, it would be ambiguous whether `case 
Variant` was introducing a new named variant with 0 parameters, 
or embedding an external type.

> - I still don't understand the appeal of bare type variants, 
> but I guess the D community loves them 🤷‍♂️.

Interesting, I think that will be the most used and most useful 
part of this feature. I strongly considered not including struct 
or tuple variants at all and *only* having bare type and alias 
cases. It allows for ad-hoc @nogc stack-based polymorphism 
without `alias this`, which is very useful.

> Is there some language I don't know about that mixes these two 
> concepts so directly? I don't mean languages that have sum 
> types AND type unions (eg Scala 3) - but some language where 
> they are mixed together, as in your DIP here?

Well, when you think about it, it's just 1 step removed from the 
Rust-style:
```rust
enum Nums
{
     Integer(i32),
     Long(i64),
}
```

It just removes the boilerplate of having to wrap them in a named 
tuple. The only real reasons the boilerplate is useful are 
because it allows wrapping the same type or set of types in 
different names, and a descriptive name being useful in some 
cases, e.g.:
```d
enum union Token
{
     case Equals(string),
     case Plus(string),
     case Mul(string),
     ...etc.
}
```

which is why I left it in. If I were to remove anything, it'd be 
tuple/unit variants.

> I wish we could just start with a very simple, conventional, 
> no-frills sumtype (named values + optional tupled arguments) 
> and then expand from there in the future. Isn't that what Swift 
> has today? That's *all* F# has or will ever have, and it's 
> incredibly powerful even in that simple form.

F# is a very different language from D. It's not generally used 
for systems programming that I know of, and it takes a lot of 
inspiration from the ML family of languages. The "union of bare 
types" pattern is extremely common in systems languages.

> At any rate, your DIP's got the minimal feature set I want, for 
> my simple needs. Good luck!

Thank you 👌