Tagged unions [Was: What's wrong with std.variant.Variant?]

[Paul Backus]

On Monday, 15 June 2020 at 16:06:15 UTC, Dukc wrote:
> On Monday, 15 June 2020 at 12:41:03 UTC, Paul Backus wrote:
>> I'm not sure what you mean by 'base class.' Are you referring 
>> to the lack of built-in support for named members? It would 
>> not be terribly difficult to add a syntax for named SumType 
>> members similar to std.typecons.Tuple, so that you could write
>
> I understood correctly, SumType automatically implements the 
> member functions that all the member types do. In that regard 
> it becomes a kind of base class for all the types specified. 
> Thats also what the `TaggedAlgebraic` types of the 
> Taggedalgebraic package (as opposed to `TaggedUnion`s) does 
> IIRC.

SumType does not implement any member functions other than the 
ones listed in its documentation [1]: opAssign, opEquals, 
toString, and toHash.

I am curious how you arrived at this misconception. Is there a 
way I can improve SumType's documentation to make its behavior in 
this regard clearer?

[1] https://pbackus.github.io/sumtype/sumtype.SumType.html

>> ...and have SumType take care of all the `Typedef` stuff for 
>> you. So far I've held off on it because I figured it was easy 
>> enough already to do by hand, but if this is a feature that a 
>> lot of people want, I can certainly add it.
>
> I think it's just about how you think about the type tag. If 
> you think it just as an internal bookkeeper of what type is in, 
> your current design is good. But if you want to base program 
> logic directly on the tag value, then you get the opinions I 
> have. Check Rust's `enum` types, they are a perfect example of 
> my school of thought.

In both Rust's `enum` types and SumType, you cannot access the 
tag directly. Instead, you must use pattern-matching.