Re: [boost] Re: enable_if formal review ?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-08-21 08:47:41

David Abrahams wrote:
> "Peter Dimov" <pdimov_at_[hidden]> writes:
>
>> David Abrahams wrote:
>>> Jaakko Jarvi <jajarvi_at_[hidden]> writes:
>>>
>>>> 4. Non-SFINAE compilers
>>>>
>>>> Dave has an implementation of enable_if which defaults to being
>>>> always enabled for compilers that do not support SFINAE. We do not
>>>> think this is the right approach, and believe that attemts to use
>>>> enable_if on a compiler that does not support SFINAE, should cause
>>>> an immediate error.
>>>
>>> Can you justify that choice a bit?  In the applications where I've
>>> used it, no-op behavior provides good gradual degradation in
>>> functionality (I don't have a strong opinion though).
>>
>> template<class X, class Y>
>>   typename enable_if<is_expression<X>::value ||
>> is_expression<Y>::value, ...>::type
>>   operator+(X const & x, Y const & y);
>
> Yes, I have precisely such a situation (see
> boost/python/object_operators.hpp).  I put those in an isolated
> namespace with the "expression" template, which gets us 90% of the
> way there.  The last 10% is given by enable_if, when available.

In some cases it is not possible to rely on ADL to find op+. Consider the
case _1 + 5. ADL works if the _1 refers to your own placeholder, defined in
boost::lambda (for instance.) But the _1 from std::placeholders won't work
unless you bring operator+ in scope. In short, sometimes you want the
operator to match types that aren't your own.

I'm not sure how important this is, though; no strong opinion from me
either.