On 14.09.24 23:48, Jordan LeDoux wrote:
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? 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? 3. Do you feel there were any glaring design weaknesses in the previous RFC that should be addressed before it is re-proposed? 4. Do you feel that there is ANY design, version, or implementation of operator overloads possible that you would support and be in favor of, regardless of whether it matches the approach taken previously? If so, can you describe any of the core ideas you feel are most important?
Hello Jordan, Happy you are following up on operator overloads, as I was sad to see the vote fail last time. I think the RFC might benefit from focusing on the comparison operators and the basic arithmetic operators this time, so ==, <=>, +, -, *, / (and maybe % and **). I would especially leave out the bitwise operators (for a possible future RFC), as those to me seem extra niche and not very self-explanatory in terms of good use cases/examples. ==, <=>, +, -, * and / would deliver almost all the benefits to operator overloading I can currently think of. Giving more concrete examples in the RFC of places in the current PHP ecosystem where these operators would simplify code might be helpful - the last RFC had mainly a generic list of use cases, but seeing actual code would help to make it salient how some code can be a lot more readable, especially if you now know about even more use cases than 3 years ago. Otherwise I am hoping that more opponents of operator overloads will chime in and give some constructive feedback.
