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

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2007-04-28 12:57:42

On 4/28/07, Peter Dimov <pdimov_at_[hidden]> wrote:
> Daniel Walker wrote:
> > On 4/27/07, Peter Dimov <pdimov_at_[hidden]> wrote:
> >> Daniel Walker wrote:
> >>
> >> [...]
> >>
> >>> _1 == _2 // ambiguous
> >>> lambda::hold(_1) == _2 // lambda expression
> >>> lambda::release(_1) == _2 // 3rd-party expression
> >>
> >> I think that the right thing here (if we take the interoperability
> >> issue to heart) is to make
> >>
> >>     _1 == _2
> >>
> >> "just work". It's an interesting challenge, but it's not impossible
> >> since that is exactly what is_bind_expression is intended to solve.
> >
> > OK, I think you're bring up something new here with is_bind_expression
> > that I haven't thought of yet. But first back to placeholders. _1 ==
> > _2 will "just work" as long as lambda is the only party overloading
> > operator==.
>
> It won't if you haven't included a lambda header or if you're using a
> compiler that is supported by Bind, but not by Lambda.
>
> The idea of "just works" is that _1 == _2 for Bind placeholders should be
> resolved by Bind without an ambiguity, yet it should still be recognized by
> Lambda as a subexpression. _1 + _2, however, should be picked up by Lambda
> because Bind does not support operator+, only relations and logical not.

So, you mean that Bind is definitely going to overload the relational
operators. Is that also  under consideration by the standard
committee? Why not bring all the operators into bind and remove (or at
least largely remove) the need for a separate lambda library to
support lambda expressions?

Daniel