Why does std.variant not have a tag?

[Johannes Pfau]

Am Mon, 05 Nov 2012 07:33:47 +0100
schrieb "Robert Jacques" <sandford at jhu.edu>:

> On Sunday, 4 November 2012 at 22:33:46 UTC, Alex Rønne Petersen
> wrote:
> > On 05-11-2012 00:31, evansl wrote:
> >>   http://dlang.org/phobos/std_variant.html
> >>
> >> says:
> >>
> >>  This module implements a discriminated union type (a.k.a. 
> >> tagged union,
> >> algebraic type).
> >>
> >> Yet, the wiki page:
> >>
> >>   http://en.wikipedia.org/wiki/Tagged_union
> >>
> >> says:
> >>
> >>   a tag field explicitly indicates which one is in use.
> >>
> >> and I don't see any indication of a tag field in the 
> >> std_variant.html
> >> page.  Another wiki reference:
> >>
> >>   http://en.wikipedia.org/wiki/Disjoint_union
> >>
> >> is more explicit because it pairs the tag with the value:
> >>
> >>   (x,i)
> >>
> >> where x is the value and i is the tag.
> >>
> >> One reason for an explicit tag is that the bounded types may 
> >> contain
> >> the same type twice.  This has lead to problems in 
> >> boost::variant as
> >> evidenced by the post:
> >>
> >>   
> >> http://article.gmane.org/gmane.comp.parsers.spirit.general/17118
> >>
> >> In addition, both variant and tuple have a common part, a 
> >> metafunction
> >> mapping from a tag to a type; hence, this same common part 
> >> could be used
> >> to implement both tuple and a tagged variant.
> >>
> >> A variant which actually contained a tag field I think would 
> >> be more
> >> general in that it would allow duplicate types among the 
> >> bounded types
> >> just as a tuple's bounded types can contain duplicate types.
> >>
> >> -regards,
> >> Larry
> >>
> >
> > Yes, this is a big problem with the current std.variant 
> > implementation (among other problems such as no recursive 
> > variants....). The best std.variant can offer right now is the 
> > 'type' property to identify what's stored in it.
> >
> > std.variant is, unfortunately, not very useful if you want the 
> > semantics of variants in ML-style languages.
> 
> I've been working on an update to std.variant whose formal
> submission has been held up by a PhD thesis and some health
> issues, although I'm currently (slowly) doing a code
> review/cleanup of it in the hope of finally submitting it. ( Old
> code: https://jshare.johnshopkins.edu/rjacque2/public_html/ )
> Anyways, my implementation has an internal 'tag' as does the
> current implementation, IIRC. However, as the tag is a
> meaningless random number, instead .type is provide access to the
> meaningful typeinfo object of that class. And .type provides most
> (all?) of the functionality of an int id:
> 
> auto var = Variant(5);
> if(var.type == typeid(int)) {
>       // Do something...
> } else if(var.type == typeid(string)) {
>      // Do something else...
> }
> 
> But I am missing something as I found that the linked post wasn't
> clear what the exact issue was, only that there was an issue. If
> someone would like to clarify the problem (or any other with
> Variant) it would be appreciated.
> 

A little off-topic, but IIRC the typeid stuff is only used to allow
arbitrary types in Variant. This is a valid use case, but could we use
a simple enum/integer tag for Algebraic? There was a discussion about
Variant's performance some time ago and if you don't need to store
arbitrary types you're currently better of writing a custom
discriminated union than using Algebraic.