Second draft: Sum Type by Struct

[Richard (Rikki) Andrew Cattermole]

On 04/09/2026 2:07 AM, monkyyy wrote:
> On Thursday, 3 September 2026 at 11:45:12 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> If all covered AND catch-all present → error: redundant catch-all
> 
> breaks meta programming norms for no reason; trailing comma reasoning
> 
>> Variants    Tag Type    Size
>> 1–256    ubyte    1 byte
> 
> 0-1 variants should have a tag of void[0] or something

They don't exist.

Its basically an alias.

> `__sumtype mynone=None;`
> 
>> None as the basis for Option
> 
> Im not seeing a pointer, like none you expand the field by 1 and it 
> cleans up allot downstream.

I don't know what this means.

Why would a pointer be involved here?

Nor why you expand the fields.

Structs of size 1 with no fields still go into the anonymous union, they 
have to (I wanted to remove them).

> `__sumtype opt=None|int|float|opt*` does it naturally just work? or will 
> it need a keyword like `this*`

It shouldn't need new syntax if it were to work.

However it does not currently.

```
testsumtypematching\start.d(100): Error: alias `start.SelfRef` recursive 
alias declaration
__sumtype SelfRef = int | SelfRef*;
```

This works:

```d
__sumtype SelfRef2 = int | SelfRef2S*;

struct SelfRef2S {
     SelfRef2 value;
}
```

Most likely its an eager analysis issue of the variants, for which I 
needed semantically analyzed. I expect I can do a check for pointer and 
make it work. So bug.

>> The generated members are the same as the non-template form. For S! 
>> (int, string) — int | string | bool — the lowered struct has six 
>> members: tag, __v0, __v1, __v2, toHash, and opCmp:
>> static assert(__traits(allMembers, S!(int, string)).length == 6);
> 
> this is a bad trait given that metaprogramming will want to access the 
> type list
> 
> `alias gettypes(Sumtype)= StaticMap! 
> (templatetypeof,__traits(allMembers,SumType)[1..$-2]);` does N inits and 
> thats with assumptions phoboes will not make and theyll add a filter, 
> add an contract, etc. etc. etc.
> 
> but the data should just be there somewhere, just add a new trait.

Not against it, we can add it later if we need to, doesn't need to be in 
the DIP.

Should also work:

```
typeof(st.tupleof[1 .. $])
```