Sum Types - first draft

[Dukc]

On Tuesday, 10 September 2024 at 04:06:16 UTC, Walter Bright 
wrote:
> https://github.com/WalterBright/documents/blob/96bca2f9f3520cf53ed5c4dec8e5e2d855e64e66/sumtype.md
>
>
> I wrote that some time ago back in November 2022. The idea is 
> to have a sumtypes proposal, followed by a match proposal.
>
> Previous discussions:
>
> https://www.digitalmars.com/d/archives/digitalmars/D/sumtypes_for_D_366242.html
>
> https://www.digitalmars.com/d/archives/digitalmars/D/Sum_type_the_D_way_366389.html
>
> https://www.digitalmars.com/d/archives/digitalmars/D/draft_proposal_for_Sum_Types_for_D_366307.html

Reviewing without having looked at other replies first.

Please study `std.sumtype` a bit more. You list many shortcomings 
that aren't actually there. It very much 
[can](https://dlang.org/phobos/std_sumtype.html#.match) provide a 
compile-time error if not all arms are accounted for. It is safe 
to use with an int and a pointer. And it can provide regular enum 
members, albeit in [a bit roundabout 
way](https://forum.dlang.org/post/dgghljgygysqvbrdpwsi@forum.dlang.org).

Also, everything I wrote 
[here](https://forum.dlang.org/post/gtzhxulfcjsrmkbxgsql@forum.dlang.org) still applies. Pasting here for reference.

> We don't want this special case for pointers - or at least it 
> needs to be much, much more refined before it carries it's 
> weight. If I have sumtype S { a, int* b }, S.a == S.b(null);, 
> right? Well, why doesn't the DIP say the same should happen 
> with sumtype S { a, Object b } ? Even more interesting case, 
> sumtype S { a, b, c, d, bool e}. A boolean has 254 illegal bit 
> patterns - shouldn't they be used for the tag in this case? And 
> what happens with sumtype S {a, int* b, int* c}? Since we need 
> space for a separate tag anyway, does it make sense for null b 
> to be equal to a?
>
> The proposed special case doesn't help much. If one wants a 
> pointer and a special null value, one can simply use a pointer. 
> On the other hand, one might want a pointer AND a separate tag 
> value. To accomplish that, the user will have to either put the 
> 0 value to the end or do something like sumtype S {int[0] a, 
> int* b}. Certainly doable, but it's a special case with no good 
> reason.
>
> The query expression is not a good idea. This introduces new 
> syntax that isn't consistent with rest of the langauge. 
> Instead, I propose that each sumtype has a member function has, 
> that returns a DRuntime-defined nested struct with an 
> opDispatch defined for quessing the tag:
> ```
> sumtype Sum {int a, float b, dchar c}
>
> auto sum = Sum.b(2.5);
>
> assert(!sum.has.a);
> assert(sum.has.b);
> assert(!sum.has.c);
> ```
> Alternatively, we can settle for simply providing a way for the 
> user to get the tag of the sumtype. Then he can use that tag as 
> he'd use it in case of a regular enum. In fact we will want to 
> provide tag access in any case, because the sum type is 
> otherwise too hard to use in switch statements.