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

[Dukc]

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.

But as you can imagine, it isn't necessarily a good thing for my 
`PictureSize` example. Consider `aPictureSize[1] += 10;`. If I 
did that, it is unlikely that I wanted to add 10 to picture 
height, regardless of the units. More likely scenario is that I 
forgot to specify the units I'm assuming `PictureSize` to be in. 
Thus, I prefer a compiler error when it happens.



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

So if you want, you could do like Taggedalgebraic and have two 
types, one for each school. On the other hand, there is nothing 
wrong in just picking the audience and let others look for 
something else.