On Thursday 11 March 2004 10:27 am, Peter Dimov wrote:
Douglas Gregor wrote:
The benefit is that we don't need to introduce a "function_equal" to compare functions and we can still choose whether to support (bind(f, _1) == bind(g, _1))(5)
But there's still the implicit assumption that not introducing function_equal is a benefit. I don't see why this should be so clear cut. What particular problems do you see with function_equal?
I don't use string_equal for strings or shared_ptr_equal for shared_ptr's, so why should I do so for function objects? Function objects are objects, they just happen to have a function call operator. The only reason I can see for us avoiding using operator== is that Lambda has already hijacked this operator for something entirely different. That doesn't seem like a great reason to force everyone else using other libraries to use "function_equal" instead of the more natural operator==. We're only allowing bind(...) == bind(...) when the types are equivalent, right? So we're only realy worried about the very, very narrow case where we have lambda-expr-1 == lambda-expr-2 and the two operands have exactly the same type. We have a way to deal with this case using an implicit conversion to bool, so why does it weigh so heavily on our minds? Or is there another reason to avoid operator==? Doug