Second draft: Sum Type by Struct

[Nick Treleaven]

On Friday, 4 September 2026 at 08:20:42 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> On 04/09/2026 7:30 PM, Meta wrote:
>> 4. Match arms being allowed to return separate types and 
>> silently evaluating to a newly synthesized sumtype is just 
>> asking for trouble. It's going to be a source of a lot of 
>> frustration and compiler errors, and potentially even bugs.

I also think an inferred sumtype result is surprising. What if I 
want the result type of the match expression to be inferred from 
the common type of all the results, how would I even write that? 
I think inferred common type should be the default, which is 
consistent with the `?` operator.

There should be some way to manually specify the result type 
(which could be a sum type or not), the compiler is not always 
going to get the desired type whatever the rules. E.g. 
`expr.match -> int { ... }`. And it would indeed be nice to allow 
that result type to be another sum type.

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.

> 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).