Hello again internals! Thank you all for the feedback that you've provided on my initial inquiries about this feature. Several bits of feedback I've received have resulted in changes to the proposal as it stands and made this a better proposal. First, the RFC has been moved to the wiki:
https://wiki.php.net/rfc/user_defined_operator_overloads The RFC is very long, as it contains a lot of research into the topic, which is part of the reason I'm bringing it to discussion so early. Work has also begun on an implementation, for which the draft PR can be viewed here: https://github.com/php/php-src/pull/7388 As the PR indicates, there is still a ways to go before a finished implementation is ready, however the RFC document appears complete enough now to be opened for discussion. Again, as I've indicated before, I'm taking my time with this, so there won't be a vote prior to a final implementation being reviewable. It is possible that this RFC will involve some changes to opcache as well as new opcodes for > and >= in order to maintain consistency of operand precedence in execution, and that's something I want to take my time with and listen to a lot of feedback on. Its impact is currently unknown as the implementation for it is unfinished. Some key points for this proposal as it is currently: - TypeErrors from the operator methods are thrown immediately instead of being suppressed. - The parameter for the other operand must be explicitly typed; an omitted type is not considered mixed for these methods. Reasoning explained in the RFC. - Type coercion still occurs as normal when strict types is not used. - The return type of the == operator function is restricted to be a bool. - The return type of the <=> operator function and all implied operators (<, <=, >, >=) is restricted to be int and is normalized to -1, 0, 1. - User classes are forced to implement overloads to work with the supported operators, resulting in an InvalidOperator exception if unimplemented. (This is a BC break, but impact is anticipated to be low) - The <=> operator instead falls back to the existing comparison logic if the overload is unimplemented. - The special cases of $obj == null and $obj == false return the expected bool value even if the overload is unimplemented. - Internal classes silently fail-over to existing operator logic. (This mainly affects ==). - Enums are allowed to utilize operator overloads, but unlike other classes, are not forced to and fall back to existing logic for comparisons. - The proposal is for dynamic methods instead of static methods, with reasoning explained in the RFC. - The identity operator === is not overloadable to prevent possibly terrible misuse. - Interfaces are not suggested or proposed, with reasoning explained in the RFC. Open questions: - Should this RFC include the bitwise operators or remain limited to the minimal set of math operators? - Should the == operator fail-over to existing behavior for all classes if unimplemented, not just internal ones? (This would reduce BC break, but make catching implementation errors more difficult for userland code.) - Should implicit interfaces be provided for the overloads? (Actual interfaces cannot be provided except for if my previous Never For Parameter Types RFC were adopted.) Thank you for all the feedback and help so far. Jordan
