[boost] Re: Variant size bug?

From: Eric Friedman (ebf_at_[hidden])
Date: 2003-11-03 19:05:02

David Abrahams wrote:

> Eric Friedman <ebf_at_[hidden]> writes:
> 
> 
>>No offense, but I believe it is a *terrible* idea for any type to have
>>the dual meanings of 'type sequence' and 'value type'. I've raised
>>this before; see
>>http://lists.boost.org/MailArchives/boost/msg46807.php.
>>
>>As always, please feel to tell me if/why I'm wrong.
> 
> 
> I understand your argument, but I'm uneasy about the idea that certain
> Concepts are ineligible for multiple-refinement.  IOW: why are type
> sequences special?  They *can* be passed by value (at least all of the
> one's I've seen can).

Yes, they can be but I don't believe that implies they *should* be.

> It's not unusual to have values that convey nothing other than type
 > info (see the std iterator tags).

True, but if these tags were not empty classes but instead stateful, 
heavy-duty classes, I think you'd have to be crazy to pass them by 
value. So I don't know how well this analogy applies.

In my code, I typically prefer pass-by-pointer or pass-by-type<>-wrapper 
over pass-by-value when the goal is to transmit type information.

> I see no reason you shouldn't be able to make a variant containing an
 > mpl type sequence.

What would be the value of this over variant< type< type-seq > >?

I think the benefits of the variant< type-seq > syntax as equivalent to 
variant< type-seq[0], type-seq[1], ... > far outweigh the benefits of 
making variant directly store what should in my opinion be an empty type.

IMO, all templates with 'variadic' template parameter lists should adopt 
this F< type-seq > == F< type-seq[0], type-seq[1], ... > convention.

> My feeling is that the most-principled (if not most-convenient)
> design for variant would change the current usage
> 
>    variant<some-mpl-type-sequence>
> 
> into
> 
>    variant<variant_types<some-mpl-type-sequence> >
> 
> and leave 
> 
>    variant<some-mpl-type-sequence>
> 
> for the case where you actually want an instance of
> some-mpl-type-sequence in the variant.

Hmm, all I can say is that I have exactly the opposite position ;)

Eric