Re: [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Sun, Sep 15, 2024 at 9:12 PM Larry Garfield <larry@garfieldtech.com> wrote: > > The "multiply by -1 for <=>" bit I don't fully understand the point of. > The RFC tries to explain, but I don't quite grok it. > > I will perhaps respond with more detail to the rest of your message later, but I wanted to address this specifically, because I also feel that the original RFC I wrote didn't explain that well. The situation this bit was referring to is as follows: You have an object Foo that implements an overload for the <=> operator.. The proposed signature for <=> was simply: operator <=>($other): int This operator did not have an OperandPosition argument. The reason for this was to prevent developers from creating situations where 5 > $foo is true and 5 < $foo is true. Instead, internally it did the same sort of reordering that the engine currently does. It calls the implementation the developer defined, and then checks if the object that the implementation was called from was on the right side of the operator. If it was, then it multiplies the result of the user defined overload by -1. Multiplying the result of the overload ONLY when the overload is called for the right side is equivalent to flipping the order. So 5 > $foo is multiplied by -1 and then evaluated as if it were $foo < 5. This is an edge case, but it was an important one in my mind. It would be entirely unnecessary if we allowed the <=> overload to know what position it was in, but that would enable lots of developer mistakes in my mind for no real gain. Instead, developers should just implement the overload as if the object assumes it will always be called from the left side of the comparison. Jordan