> I think it's fairly crucial that this proposal is NOT just about overloading operators, it's about overloading *behaviour*
That is what this RFC is trying to achieve. Equivalent in behaviour, so we're providing a way for a class to define how it compares or equates to another value. We're not providing a way to override the meaning or function of the comparison operators, and it's up to the implementor to follow this advice. There's nothing stopping someone making `>` modify the object. But that's the nature of user-defined behaviour of operators: giving a developer more flexibility also increases the amount of weird stuff they can do. The question is simply whether the value of the flexibility is more than the cost of the potential for misuse. We're proposing the ability for a user to determine how a class should be compared to another value. The ability to change the semantics of the comparison operators is an unavoidable side effect. > If someone implements __compareTo() just to give some domain-specific meaning to the <=> operator That would be bad implementation on their part, and we should mention in the documentation update that this is not the intended application. > 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. Currently they do attempt to convert to boolean and integer, respectively, but that doesn't achieve much because you can still return nothing in either case and the coercion would be 0 and false. -- The decision whether to accept this will come down to the trade-off between flexibility and potential for misuse. We're giving the developer more power and responsibility by adding to the capability of the language, but that can be said for any language-level change that has the potential for misuse. I would personally opt for more flexibility, with clear direction on the intended use, and trust that those who decide to leverage it know what they're doing. On Fri, 29 Jun 2018 at 13:35, Rowan Collins <rowan.coll...@gmail.com> wrote: > 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] >
