From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-11-15 11:32:23
David Abrahams wrote:
> "Peter Dimov" <pdimov_at_[hidden]> writes:
>> David Abrahams wrote:
>>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>>>>> Or variant_from_sequence<mpl-seq>::type?
>>>>> OK, sure.
>>>> I take it back. The only correct interface is variant<mpl-seq>,
>>>> without the variable-length enhancement.
>>> I'm confused about what you mean. Isn't that the one we already
>> We have
>> variant<T1, T2, ..., Tn>
>> There are two problems with it. First, there is a collision when n
>> == 1. Second, if I write
>> template<class Seq> void f( variant<Seq> const & v );
>> my function will not match all variants.
> Hmm, good point. The obvious question "what if you want to match a
> variant with only N component types?" yields two obvious answers:
> 1. Why would anyone want to do that
> 2. enable_if
> On the other hand, with an is_variant metafunction you could do
> template<class V>
> enable_if<is_variant<V>,void>::type f( V const & v );
Yes, I considered that. It's not that it's impossible to write f, the
problem is that the natural way doesn't work, or rather, it works with a
particular subset of all variants, one that has the power to cover all the
variant space. So one easy way to avoid the issue is to just locally ban the
T1..Tn syntax and then demand that users do so, too. Which means that the
flexibility offered by the current variant<> is now a liability.
I'm somewhat amused by the possibilities that enable_if offers. Perhaps one
day we'll think of
template<class V> enable_if< is_instance_of< std::vector<_, _>, V> >::type
f( V & v);
as a natural alternative to
template<class T, class A> void f( std::vector<T, A> & v );
but I doubt it. ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk