Second draft: Sum Type by Struct

[Nick Treleaven]

On Wednesday, 9 September 2026 at 16:40:54 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> On 10/09/2026 4:06 AM, Nick Treleaven wrote:
>> I was trying to say that one solution (which I think supports 
>> the core use cases better) may be to have special AST 
>> *statements* for these:
>> 
>>> T v = e.match { ... };

This is the important one above to support...

>>> return e.match { ... };
>> 
>> I.e. no expression is parsed for `e.match {...}` in the above 
>> 2 lines.
>> 
>> However I know for this DIP you wanted to be able to chain 
>> match expressions. I agree that could be useful, but I don't 
>> think it is a core use case. I would sacrifice the ability to 
>> do that in order to have full use of statements in the match 
>> arms.
>
> Chaining has no relation to not supporting statements.
>
> The compiler cannot do it without massive changes.

Here is how it would work for this example:

```d
// below is a MatchDeclarationStatement
R r = st.match {
     (U u) {
         if (u == u2)
             return; // return from the enclosing function
         break r1; // set `r` to `r1`
     }
     (V v) => r2;
};
```

Lowering:
```d
R __r = void;
auto __e1 = st;
if (__e1.tag == 0) {
     U u = __e1.__v0;
     if (u == u2)
         return;
     emplace(__r, r1);
}
else {
     V v = __e1.__v1;
     emplace(__r, r2);
}
R r = __r.move;
```

For `expr.match` used as an expression elsewhere, it could still 
lower to your chain of conditional expressions. So chaining would 
be possible, just not with statement arms.