Re: [boost] [bind][tr1] patch for more compliant placeholders

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-04-29 11:46:49

Daniel Walker wrote:

>> !boost::bind(...): Bind
>
> Task for bind: None. This works as is.
>
> Task for lambda: operator! needs to be supplied for std::bind but
> disabled for boost::bind.

I'm planning to propose std::bind relational operators and operator! for the 
next meeting. They may or may not actually go in, of course. I'm still not 
sure that I have the design 100% right, though. The basic idea is to add

template<class L, class R>
    typename enable_if<
        is_bind_expression<L>::value ||
        is_placeholder<L>::value ||
        is_bind_expression<R>::value ||
        is_placeholder<R>::value,
        ...>::type
    operator==( L const & l, R const & r )
    {
        return bind( __equal_to(), l, r );
    }

where __equal_to()(x,y) returns x == y.

The interesting issue is in which namespace we need to add the above. The 
global namespace works most of the time, is contrary to the spirit of the 
rest of the standard, and fails when an operator== overload in the current 
scope hides the global one.

Namespace std is in line with the rest of the standard, but doesn't work for 
the placeholders via ADL, since these are defined in namespace 
std::placeholders. In other words, _1 == 5 will fail by default unless there 
is a "using namespace std" directive in effect.

The best solution I have so far is to define the operators in std, move the 
placeholders into std as well and import them into std::placeholders with 
using declarations. This preserves the original use case of "using namespace 
std::placeholders" making only _K visible, while still keeping std as an 
associated namespace for ADL purposes, so that _1 == 5 finds the above 
std::operator==.

It should probably be noted that this will fail if Herb Sutter's "Fixing 
ADL" proposal is accepted.

This is also an interesting use case for a || concept requirement. I'm not 
terribly familiar with the concepts proposal though; it might offer an 
alternative solution that I don't know about.