Hey Jordan,

I've voted "no" on this one: infix functions may have been interesting,
but adding a whole new type system around operators is really not worth it,
given:

• Added AST nodes
• Added method definitions for niche use-cases
• Complexity in support for static analysis tools

I personally don't see a reason to introduce all this for examples like
the one with GMP, which was more readable before adopting userland custom
operators.

In addition to all that, we didn't even achieve custom operators anyway:
it's just the built-in ones (this is why I mentioned infix functions), and
the precedence, number and type of operands are fixed too (yes, it is a
sensible starting choice, but very little "custom" about it).

Overall, your RFC is exactly what I would expect a custom operator RFC for
PHP to look like: I just don't think the feature is needed at all, as it
only makes the language much more complex, for rare cases that I hope I
will never ever have to debug in future.

Greets,

Marco

Thanks for articulating your reasons for your vote, I very much appreciate
it.

For the record, I don't think that my RFC precludes infix functions in a
future RFC, and in fact I think setting up a new keyword makes that simpler
in the future.

Jordan

Hey Jordan,

I've voted "no" on this one: infix functions may have been interesting, but
adding a whole new type system around operators is really not worth it,
given:

• Added AST nodes
• Added method definitions for niche use-cases
• Complexity in support for static analysis tools

I personally don't see a reason to introduce all this for examples like the
one with GMP, which was more readable before adopting userland custom
operators.

In addition to all that, we didn't even achieve custom operators anyway:
it's just the built-in ones (this is why I mentioned infix functions), and
the precedence, number and type of operands are fixed too (yes, it is a
sensible starting choice, but very little "custom" about it).

Overall, your RFC is exactly what I would expect a custom operator RFC for
PHP to look like: I just don't think the feature is needed at all, as it
only makes the language much more complex, for rare cases that I hope I
will never ever have to debug in future.

Perhaps we need more discussion about use cases to justify this RFC?

I think the main use cases mentioned so far were for arithmetic
operations between value objects that represent money, time, or other
measurable values, or mathematical higher-order values (vectors etc).

I imagine that operator overloads can improve DX for these use cases,
but at a cost for the overall language.

How would you (Marco) see the future of arithmetic libraries for time,
money etc without overloaded operators?
How would these calculations look like e.g. with infix functions?
Do you think this can eliminate the desire for operator overloads?

E.g. something like this?

$ts0 = new Timestamp($seconds0);
$ts1 = new Timestamp($seconds1);
/** @var Duration $duration */
$duration = $ts1 - $ts0; // Operator overload notation.
$duration = Duration::betweenTimestamps($ts0, $ts1); // Static method notation.
$duration = $ts1->diff($ts0); // Object method notation.
$duration = $ts0 Duration::betweenTimestamps $ts1 // Infix notation
based on static method.
$duration = $ts1 <diff> $ts0 // Infix notation based on object method.

I generally like names I can click on, if they don't get too long..
I like if the choice of implementation is knowable by just looking at the code.
(with a small range of runtime polymorphism)
I like if some functionality is implemented outside of object methods,
keeping interfaces and inheritance chains simple.

But for code with lots of calculations, a simple "-" feels simpler and
more explanatory than something like "diff" or "timediff", where I
have to reference and remember a specific method/function name.

-- Andreas

Greets,

Marco

On Mon, Jan 3, 2022 at 1:14 AM Jordan LeDoux jordan.ledoux@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 agree wholeheartedly with this. I don't have a vote but if I did I'd vote
no. I think if operator overloading is to be introduced, new magic methods
using names like __add and __equals are preferable for a number of reasons.

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

Hi Nikita,

On Mon, Jan 3, 2022 at 1:14 AM Jordan LeDoux jordan.ledoux@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).

I hesitated too, however I think we can't escape this feature. Like it
was for the annotation, we need to find a compromise.

Your points are valid so I wonder if the RFC could be modified and get
to the point we could reach that compromise. There will be the
oppositions for the features as a whole, however I am optimistic about
our abilities to get there this time rather than wait yet again a few
years for something we know we will have anyway.

Best.

Pierre

@pierrejoye | http://www.libgd.org

Hello Jordan,
do you have any thoughts about these symmetric/left/right modifiers,
to get rid of the $operandPos parameter?

To me, the parameter could be the kind of thing where in hindsight we
ask "why?".

Also, can we drop the "public" modifier, if we do a new version of the RFC?

Cheers
Andreas

Hello Jordan,

I have another note about the RFC.
(I am not sure what's the policy, if we should continue all
discussion here or go back to the RFC thread. Hope it's ok here.)

OperandPosition::LeftSide
OperandPosition::RightSide

I wonder if this is the best way to model this.
Especially, it does not account for the case where an operator only
works in one direction, or the allowed operand type is dependent on
the direction.
E.g., (Money / float) is ok, but (float / Money) probably not supported.
Or if it is supported, then the return type will be quite different.
You can throw an exception, but this is not useful for static analysis.

An alternative syntax with a few more keywords:

abstract class Money {
symmetric operator * (float|int $other): Money; // Commutative.
left operator / (float|int $other): Money; // Only $a / $b allowed,
$b / $a not possible.
left operator - (Money $other): Money; // $a - $b
right operator - (Money $other): Money; // $b - $a
}

Btw, in the Matrix example from the RFC, under "When will $operandPos
be useful?", the $operandPos is not really useful, because it will
always pick the default $a - $b version.
The same applies to "-" operator in my Money example, because $other
already implements the operator.

The $operandPos is only needed if the left operand does not
implement the operator. Which is the case e.g. for complex numbers, or
the Number class from the RFC example.

I am trying to think of cases where ($a <op> $b) would have a
different type than ($b <op> $a), but I can't think of any.
Or rather, for any case that I could think of, the mirror operator
could simply be provided by $b.

I am not married to the modifier names, e.g. it could be "symmetric"
or "commutative" or something else.
For left/right perhaps I prefer to talk about the "default direction"
vs the "flipped direction", not sure how this could be turned into
keywords.
If we don't like more keywords, perhaps something like "!operator" for
the flipped version?

Cheers
Andreas

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

Hi Jordan,

Many thanks for all your replies. But did you miss Côme's mail (maybe
because you weren't direct recipient)? Anyway, here it is again:

Hello,

From the RFC:

If the left operand produces a TypeError due to the parameter types
listed in the implementation, the operation is not retried with the right
operand and the error is instead returned immediately. This is to help
developers encounter errors in their program logic as early as possible.

This feels wrong if I understand correctly.

Let’s say I create a class A and I want to add support for "2 / new A()",
which by default does not work.

I can do
class A
{
operator /(int $other, OperandPosition $operandPos): mixed
{
return "example";
}
}

Now someone wants to build on my work, and add a class B that supports
"new A() / new B()".

class B
{
operator /(A $other, OperandPosition $operandPos): mixed
{
return "example";
}
}

This will not work because it will first try A->{'/'}(B) that throws a
TypeError? So it means what I was able to do for floats, cannot be done for
my new classes afterwards? This is inconsistent I think. It also means it
is not possible to extend any existing class with operators interacting
with a new class, meaning you can only use operators among classes aware of
each other, most likely from the same package/library.

Also, this was stated already I think but I did not see an answer, from
RFC example:

class Matrix {
public function __construct(readonly public array $value) {}

public operator *(Matrix $other, OperandPosition $operandPos): Number
{
    if ($operandPos == OperandPosition::LeftSide) {
        // Count of my columns needs to match
        // count of $other rows
    } else {
        // Count of my rows needs to match
        // count of $other columns
    }
}

}

The second branch of the if is dead code, as $matrix1 * $matrix2 will
always call $matrix1->{'*'}($matrix2, LeftSide) and never the other way
around.
This means that $operandPos is useless in all cases where operators are
only typed againts the same type, and points to this design solution being
wrong.

There is «Why not interfaces?» in the FAQ, does that mean that operators
cannot be added in interfaces? This is not stated clearly in the RFC.

Also, it is not clear if operator overload will affect comparison
operations used in core functions such as in_array, sort and so on.
Does implementing operator == allows using in_array to find an object in
an array?
Which of these internal functions use == and which use ===, which is not
overloadable?
Does implementing operator <=> allows sorting of arrays containing my
objects?

Côme

--

To unsubscribe, visit: https://www.php.net/unsub.php

I too would be interested in your answers to those.

Best regards,

--
Guilliam Xavier

• what is the performance impact?

Each operator evaluation is very slightly better than the equivalent
function call, since the VM call chain is very slightly simpler, but for
most purposes you can think of the performance as being the same as a
method call. This is quite a bit slower than most operator evaluations
(which are lightning fast compared to function calls), however this only
affects objects used with operators, which currently always result in a
fatal error. So in that sense, there is no performance impact.

• why "[public] operator" and not "operator function"?

As many people in this thread have pointed out, it's possible for less
experienced developers to do something truly devious with this (the same
way that they can with __get, __set, or __toString). I wanted to avoid
using the function keyword at all, because I wanted the code itself to
mentally prepare the programmer to treat these differently than arbitrary
functions. As I mentioned in a previous email, some will view this as
wishy-washy, but that decision was done after consulting a specialist that
I know in the field of Human Centered Design (the field of designing
technology so that it is used correctly by design alone). That is, in
truth, my largest reason for wanting the operator keyword, but it's also
something that I invested nearly two months of study and consultation into.
That makes it difficult for me to correctly convey that understanding to
other people here via email, so I have mostly restricted my arguments to
other things. I find myself in the odd position of not really being able to
dump all of the research I did here for everyone else, because frankly, no
one on this list should need to invest a week of studying to understand
an RFC.

So unfortunately, my best argument in favor of this is one I can't really
make, but that is the reason that I went this route.

• what about precedence, i.e. what happens with $a + $b * $c? there's no
  clear answer

Precedence is handled by the compiler and how it handles the opcodes.
That's independent of any of the changes in this RFC, since the opcodes for
all the operators are the same with or without operator overloads. So the
precedence will be the same if $a, $b, and $c are ints or objects, even if
we later (for some reason) changed the precedence of the operators.

• why not allow the tilde operator to be used in a different context?,
  e.g. in PostgreSQL it is used as a regular expression match, e.g.
  $a ~ '^[a-z]+$'

This would involve changing the opcode evaluation itself, instead of just
implementing a do_operation handler in zend_class_entry. It would introduce
much more surface for buggy behavior and be a great deal of additional
effort for that single operator.

• the Implied Operators table does not mention ~= operation.

The ~= operator does not exist in PHP because the ~ operator is a unary
operator in PHP (bitwise not).

See:

• https://www.php.net/manual/en/language.operators.assignment.php
• https://3v4l.org/N9OYF

• I don't like the Reflection API changes

Please suggest changes then. It seems probable this will not pass in this
incarnation, so knowing what things to improve before bringing it back
would be helpful.

Jordan