[boost] Re: [MPL] is_sequence problem

From: David Abrahams (dave_at_[hidden])
Date: 2005-05-08 11:33:33

Joel de Guzman <joel_at_[hidden]> writes:

> David Abrahams wrote:
>> Joel <joel_at_[hidden]> writes:
>
>>>I think the problem is the way mpl::is_sequence is implemented.
>>>It tries to detect the presence of a "tag" typedef and a "begin"
>>>typedef and concludes that a type is an mpl::sequence if it
>>>has both. I've complained a long time ago about this. I think
>>>this behavior is error prone. It's quite easy to come up with
>>>a situation where I have a type T with a "tag" and a "begin"
>>>but is not an MPL sequence. There must be a better way. MPL
>>>should not monopolize on the usage of "tag" and a "begin"
>>>in a type.
>> I never liked is_sequence in the first place.  1. Anything that
>> makes structural checks is prone to masquerades like
>>    the one you cite.
>> 2. Whenever you check if something is a sequence and do something
>>    different based on that fact, genericity is broken.  We went
>>    through this discussion with boost::variant.
>> Are you sure you want to be using even a perfect implementation of
>> is_sequence?
>
> I'll have to think about this question some more. Right off the
> bat, type categorization plus enable_if allows constrained
> genericity, which IMO, is a good thing. We don't really break
> genericity, we constrain it. 

As long as you're not using it to select between behaviors, it's OK.
I'm not sure that you get better error messages by removing overloads
than if you had used a nice BOOST_STATIC_ASSERT, though.

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