Second draft: Sum Type by Struct

[Richard (Rikki) Andrew Cattermole]

On 06/09/2026 4:02 AM, Nick Treleaven wrote:
> On Saturday, 5 September 2026 at 14:54:55 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> On 06/09/2026 2:19 AM, Nick Treleaven wrote:
>>> Also, using a new set of integer promotion rules (however nice) that 
>>> aren't compatible with the C rules D inherited would need much 
>>> stronger justification, and I doubt its a good idea. That plus sum 
>>> type inference makes this DIP more complicated, and those could be 
>>> added later in a separate DIP, if needed.
>>
>> I'm not working from C's promotion rules here, they are primarily for 
>> math expressions which this is not.
>>
>> The rules I have worked based upon is the sumtype variants where 
>> multiple integer types are errors for unnamed variants. You can't know 
>> which variant to construct.
>>
>> So I want a rule that is neither lossy, nor will trigger this error.
>>
>> And no, flow sensitive typing is not something you "add on later". You 
>> do it up front or not at all.
> 
> That doesn't make sense. As I suggested, a valid design is to require 
> there to be a common type for all arms, and if not you have to specify 
> the result type manually, once. This design is simpler.

That is one way to do it, but I am aiming for it to be flow sensitive, 
and that isn't how it works for this.

>>>> TypeScript:
>>>>
>>>> ```typescript
>>>> function evaluateArm(input: "a" | "b"): string | number {
>>>>   switch (input) {
>>>>     case "a":
>>>>       return 42;        // This arm evaluates to a number (int)
>>>>     case "b":
>>>>       return "hello";   // This arm evaluates to a string
>>>>   }
>>>> }
>>>
>>> I don't know TS, but it looks like the `switch` above does not have a 
>>> result type at all. BTW I am concerned that IIUC the above pattern 
>>> (which you chose to quote), cannot be written with your proposal, 
>>> because it doesn't support `return` in a match arm (i.e. returning 
>>> from `evaluateArm` directly).
>>
>> I wanted statement arm bodies, it was in previous designs.
>>
>> But yeash there is nothing in the expression tree that would allow it 
>> (that I could find, or aware of).
>>
>> It would be a massive addition.
>>
>> We could add it later on, since expression just becomes an expression 
>> statement.
> 
> Not being able to use `return` in a match *expression* is 
> understandable. Not having a match *statement* which can use `return` 
> seems like a big omission IMO.

There is no match arm statement support.

I wanted it, but couldn't without doing a lot of work in dmd.

The problem is its going from expression to statement.
Everything is setup to go statement to expression only.

```d
st.match {
	(v) { // "=>" Statement (not supported in dmd)
		return ...; // requires rewriting (errr... looks like it should return 
from function, but doesn't me no likey)
	}
};
```

This really is the big "I wish" I have. Unfortunate.