Second draft: Sum Type by Struct

[Richard (Rikki) Andrew Cattermole]

On 10/09/2026 4:06 AM, Nick Treleaven wrote:
> On Wednesday, 9 September 2026 at 10:32:59 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> All the cases you showed as suggestions are still expressions. We 
>> cannot go from an expression to a statement in the AST. This can be 
>> fixed, its just a lot of work, and outside the scope of this DIP and 
>> implementation.
> 
> I agree my suggestion of *MatchExpInitializer* might not be possible, as 
> *ExpInitializer* can be a nested expression.
> 
> 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 { ... };
>> 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.

I wanted it to support it!

Earlier designs had:

```d
st.match {
	(v) {

	}
};
```