On Mon, Jan 3, 2022 at 1:14 AM Jordan LeDoux <jordan.led...@gmail.com> wrote:
> Hello internals, > > I've opened voting on > https://wiki.php.net/rfc/user_defined_operator_overloads. The voting will > close on 2022-01-17. > > To review past discussions on this RFC and the feature in general, please > refer to: > > - https://externals.io/message/116611 | Current RFC discussion > - https://externals.io/message/115764 | Initial RFC discussion > - https://externals.io/message/115648 | Pre-RFC discussion and > fact-finding > > Jordan > Voted No on this one. I did support the previous proposal on this topic, but I don't like the changes that this iteration has introduced relative to the previous proposal. The part that I dislike most (and that I consider an exclusion criterion regardless of any other merits of the proposal) is the introduction of a new "operator +" style syntax. I found the motivation for this choice given in the RFC rather weak -- it seems to be a very speculative forward-compatibility argument, and I'm not sure it holds water even if we accept the premise. There's nothing preventing us, from a technical point-of-view, from allowing the use of some keyword only with magic methods. On the other hand, the cost of this move is immediate: All tooling will have to deal with a new, special kind of method declaration. I'm also not a fan of the OperandPosition approach, though I could probably live with it. The previous approach using static methods seemed more natural to me, especially when it comes to operators that do not typically commute (e.g. subtraction). Regards, Nikita
