Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115764
MIME-Version: 1.0
Date: Thu, 19 Aug 2021 01:38:46 -0700
Message-ID: <CAMrTa2HBv94ui0xGsqZwP=uL3AHQDMPAhaToo7m4F5Yh5QT64Q@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003ecc0105c9e57baa"
Subject: [RFC] User Defined Operator Overloads
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000003ecc0105c9e57baa
Content-Type: text/plain; charset="UTF-8"

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

--0000000000003ecc0105c9e57baa--