On 27 June 2018 at 19:24, Levi Morrison <le...@php.net> wrote: > This permits things such as NumPy to overload < to do an element-wise > comparison of the members; something like this: > > np.array([1, 3, 5, 7]) < np.array([2, 1, 6, 6]) > // evaluates to np.array([true, false, true, false) >
In my opinion, this is exactly the kind of messy operator overloading we should avoid, but if we DO want it, then its purpose is to over-ride the syntax, not the meaning, of the operator; so "overloaded <=>" would NOT be the same as "overloaded comparison". I think it's fairly crucial that this proposal is NOT just about overloading operators, it's about overloading *behaviour* which occurs throughout the language, and as such I think this statement from the RFC is incorrect: > __compareTo is equivalent to <=> and __equals is equivalent to == If someone implements __compareTo() just to give some domain-specific meaning to the <=> operator, what will happen when someone passes those objects to sort()? If someone decides they want to return an object from __equals(), how will switch statements behave? And so on... Because of that, I would much rather these functions did enforce a return type. Note that __toString() generates an error for an incorrect return type when used, and __sleep() raises a Notice and serializes Null instead of the object. I think __compareTo() and __equals() could act more like a return type hint, and either throw a TypeError straight away, or attempt to coerce to the correct type and throw a TypeError on failure. Then, if we want the ability to override the <=> operator specifically, that can be added later, and users can return whatever type they want without breaking all the other places where __compareTo() is called. Regards, -- Rowan Collins [IMSoP]
