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

On Sat, 14 Sep 2024, Jordan LeDoux wrote: > I want to discuss what changes to the previous proposal people would > be seeking, and why. The most contentious design choice of the > previous proposal was undoubtedly the operator keyword and the > decision to make operator overload implementations distinct from > normal magic methods. For some of the voters who voted yes on the > previous RFC, this was a "killer feature" of the proposal, while for > some of the voters who voted no it was the primary reason they were > against the feature. I am still generally in favour, just like I was on the previous iteration. And yes, I would say having the "operator" keyword was a "killer feature" for me. > I hope to start off this discussion productively and work towards > improving the previous proposal into something that voters are willing > to pass. To do that, I think these are the things that need to be > discussed in this thread: > > 1. Should the next version of this RFC use the operator > keyword, or > should that approach be abandoned for something more familiar? Why do > you feel that way? Yes. Making it clear what happens is useful. > 2. Should the capability to overload comparison operators be provided > in the same RFC, or would it be better to separate that into its own > RFC? Why do you feel that way? I'm not too worried, but usually smaller RFCs have a larger chance of being accepted. cheers, Derick