Why does std.variant not have a tag?

[evansl]

On 11/05/12 13:53, Robert Jacques wrote:
> On Monday, 5 November 2012 at 14:13:41 UTC, evansl wrote:
>> On 11/05/12 00:33, Robert Jacques wrote:
>>> On Sunday, 4 November 2012 at 22:33:46 UTC, Alex Rønne Petersen
>>> wrote:
>>>> On 05-11-2012 00:31, evansl wrote:
> 
> [snip]
> 
>> If std.Algebraic is like Boost.Variant, then duplicate
>> bounded types are not allowed and leads to the problem mentioned
>> in the post on the spirit mailing list which I linked to in my
>> OP.  OOPS,  now I see why reading that post was not clear enough.
>> Maybe this earlier post in same spirit thread would be clearer.
>>
>> http://article.gmane.org/gmane.comp.parsers.spirit.general/17113
>>
>> In particular, note the phrase:
>>
>>   neither can you use variant<string,string,int>
>>   because variant can't take duplicate types.
>>
>> This can lead to problems in the spirit parser because
>> the attributes of parsing:
>>
>>     a | b
>>
>> where:
>>   phrase a has an attribute of type A
>>   phrase b has an attribute of type B
>> is:
>>
>>     variant<A,B>
>>
>> as noted near the bottom of:
>>
>>
>> http://www.boost.org/doc/libs/1_51_0/libs/spirit/doc/html/spirit/abstracts/attributes/compound_attributes.html
>>
>>
>> and if A and B are the same, then there's a problem because
>> Boost.variant can't handle duplicates.
>>
>> Hope that's clearer.
>>
>> -regards,
>> Larry
> 
> Thank you for the clarification. Implementing an id seems reasonable
> feature request for algebraic. I've added a bugzilla request for it:
> http://d.puremagic.com/issues/show_bug.cgi?id=8962 Please have a look in
> case I missed anything.

The bugzilla request looks good to me, especially the way that the
tuple and algebraic are made as similar as possible.  As I mentioned
before, the thing that's similar is the metafunction mapping from
tags to types.  Maybe that could be a future enhancement.

BTW, the idea of this metafunction map I first found in NuPrl, where
these types of functions are called type-valued functions, expressed as:

  B:(A -> U_1)

where U_1 represents all the types, primitive and user defined, in c++,
and A is something like an enum or unsigned or some other type serving
as the set of possible tag values.

The above B expression is found here:

http://www.nuprl.org/book/Introduction_Type_Theory.html#SECTION00321000000000000000


where it's used to define:

  dependent functions (corresponding to std.tuple)
  dependent products  (corresponding to std.Algebraic)

Thought you might find that interesting, as I did.
> 
>> BTW, recently there was a review of
>> another Boost library that has some similarity to
>> Boost.any.  It's called type_erasure:
>>
>>
>> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/index.html
>>
>>
>> Since std.Variant is similar to Boost.any (as noted above),
>> and since Boost.any is, in some ways, like Boost.type_erasure,
>> and since you're working on a revised std.Variant,
>> you might be interested in looking at type_erasure.
> 
> Thanks, I'll take a look at it.

IIRC, the main difference between Boost.any and Boost.type_erasure is
type_erasure can be used to put some constraints on the contained type
such as requiring the type to support certain functions.
I think type_erasure calls the constraints concepts.  You can search for
"type_erasure" here:

  http://thread.gmane.org/gmane.comp.lib.boost.devel

to access some interesting discussions.

HTH.
-regards,
Larry




-regards,