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

Dukc ajieskola at gmail.com
Sat Sep 26 21:31:36 UTC 2026


On Saturday, 26 September 2026 at 00:47:37 UTC, Meta wrote:
> I don't know what you mean by template instances in this case. 
> Are you talking about this?
> ```d
> struct S(T);
> enum union E(T) { case S!T; }
>
> switch(...)
> {
>     case S!T, T => writeln(T.stringof)
> }
> ```

No, I mean things like this:

```d
// omitting template constraint
alias HavingValue(T, bool having : true) = T.just;
alias HavingValue(T, bool having : false) = T.nothing;

alias OurType = typeof(someOptionalInt);
auto someVar = switch(someOptionalInt)
{   case HavingValue!(OurType, true)(theInt) => text("int value 
", theInt),
     case HavingValue!(OurType, false) => "no value, nothing to 
see",
}
```

>>
>> Had another look how OCaml does it. It does support wildcards, 
>> but they do not work as I proposed. Instead, they are 
>> essentially `default` cases with a variable name, the variable 
>> binding to result of the matched expression. I think that's a 
>> good alternative.
>
> The problem with that is:
> ```d
> enum union U { case int, string, bool, Unit() }
>
> switch(U.init)
> {
>     default v => ...
> }
> ```
>
> A default arm allows you to omit any number of other cases. The 
> problem is, how do you unify the types of the omitted cases 
> when they can easily all be invariant with each-other? What is 
> the type of `v` within the type system?

If we follow OCaml and Haskell, it'd be `U`.

>
> Rikki did include this in his DIP, and his solution was that it 
> acts like a template lambda or a static foreach loop. The arm 
> is duplicated automatically by the compiler for each type.

So pretty much how I first proposed wildcards act. I don't 
currently have preference whether wildcards should work that way, 
the Haskell/OCaml way, or something in-between way. You DIP 
doesn't even have to decide that, assuming you're leaving 
wildcards for another DIP. I just want to have the syntax 
reserved for it, however it'll eventually work.




More information about the dip.development mailing list