Re: [boost] [mpl] bug: mpl::is_sequence< mpl::int_<1> > fails to compile

From: David Abrahams (dave_at_[hidden])
Date: 2006-05-08 11:36:25

Joel de Guzman <joel_at_[hidden]> writes:

> David Abrahams wrote:
>> Joel de Guzman <joel_at_[hidden]> writes:
>> 
>>> David Abrahams wrote:
>>>> Tobias Schwinger <tschwinger_at_[hidden]> writes:
>>>>
>>>>> Why not make is_sequence work reliably? 
>>>> Because it's impossible.  It's always going to look for some features
>>>> of the type being tested that can be present even if the type is not,
>>>> in fact, a sequence.
>>> I don't see why it is impossible. MPL sequences can always
>>> specialize is_sequence<T>. is_sequence *can* work reliably
>>> 100% of the time:
>>>
>>>      template <class S>
>>>      struct is_sequence : mpl::false_ {}; // default
>>>
>>>      // your specializations here
>> 
>> The problem isn't false negatives, it's false positives.  In practice
>> you can probably make it vanishingly unlikely that some random
>> third-party type will pass all the default is_sequence tests, but you
>> can never make it 100% impossible as long as:
>> 
>>   a. sequences can be arbitrary types, such as void(int,long,char)
>> 
>>   b. is_sequence<S> reporting correctly is not part of the sequence
>>      requirements
>
> Is that a or b? or a and b?

I think it's OR.

> I believe that the default is_sequence should strictly be
> mpl::false_: no guessing games.
>
> I think:
>
> a) if you want to make specific types (e.g. RT(A0,A1,...AN)),
> a sequence, then specialize is_sequence for those. 

ODR violations ensue.  int(int,long) is a sequence in one TU but not
in another.

> Sure you can do it for only a limited number of args, but, hey, so
> do other libraries that provide traits over function types/ member
> function pointer types, function pointers.  Are there other
> arbitrary types you have in mind that can be sequences? If there
> are, specialize for them. Explicit is better than implicit, right? I
> think the guessing game where MPL is trying some heuristics as to
> how an MPL sequence looks like (e.g. it has a tag typedef, etc), is
> what's causing us problems. I think it is the wrong approach.
>
> b) If is_sequence is part of MPL's public interface, then it
> should give reliable results. If that requires b, then so be it.

Right.  Which is why I encouraged Aleksey to remove it.  I'm surprised
it's even documented in the reference manual.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com