On 4/28/07, Peter Dimov <pdimov@mmltd.net> wrote:
Daniel Walker wrote:
So, you mean that Bind is definitely going to overload the relational operators.
Bind already overloads the relational operators:
Aha, that was the source of my confusion. I'm not so worried about bind(f, _1) < x. This already works even when the lambda header is included. Moving forward, I think breaking this code can be avoided. I'm worried about bind(f, _1 < x) or bind(f, _1) < _2.
in more limited contexts. It is trivial to extend this overloading to work on expressions that involve no bind calls such as _1 == 5, _1 > _2 or !_4 - provided that the placeholders aren't inline functions, of course. :-)
It's also trivial to make lambda generate is_bind_expression specialized functors. I think one or the other of the libraries should take care of this use-case but not both, just to avoid the head aches. But again, if one of the libraries provided a hold function to claim the placeholder it could resolve the problem.
Is that also under consideration by the standard committee?
Not yet.
Then this is TR1++. ;-) Which is fine by me, actually. I would like to have a one-stop-shop for all my on-fly, unnamed-function-creation needs. But I don't want to wait 10 years for it. The past decade of dealing with bind/lambda incompatibility has been irritating enough. I think just making lambda work with the new standard will go along way toward alleviating these inconveniences. In the long run, it would be nice if lambda and bind were folded together though.
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?
The operators that Bind currently supports do not require return type deduction since their return type is assumed to be bool.
That makes sense. Daniel