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.
