On 4/28/07, Peter Dimov <pdimov@mmltd.net> wrote:
Daniel Walker wrote:
On 4/27/07, Peter Dimov <pdimov@mmltd.net> 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