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
>>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, type-seq, ... > 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, type-seq, ... > convention.
> My feeling is that the most-principled (if not most-convenient)
> design for variant would change the current usage
> variant<variant_types<some-mpl-type-sequence> >
> and leave
> 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 ;)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk