Am Mon, 05 Nov 2012 07:33:47 +0100 schrieb "Robert Jacques" <[email protected]>:
> 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.
