[Pre-RFC Discussion] User Defined Operator Overloads (again)

Hello internals,

This discussion will use my previous RFC as the starting point for
conversation: https://wiki.php.net/rfc/user_defined_operator_overloads

There has been discussion on list recently about revisiting the topic
of operator overloads after the previous effort which I proposed was
declined. There are a variety of reasons, I think, this is being
discussed, both on list and off list.

1. As time has gone on, more people have come forward with use cases.
   Often they are use cases that have been mentioned before, but it has
   become more clear that these use cases are more common than was
   suggested previously.

2. Several voters, contributors, and participants have had more time
   (years now) to investigate and research some of the related issues,
   which naturally leads to changes in opinion or perspective.

3. PHP has considered and been receptive toward several RFCs since my
   original proposal which update the style of PHP in ways which are
   congruent with the KIND of language that has operator overloads.

I mentioned recently that I would not participate in another operator
overload RFC unless I felt that the views of internals had become more
receptive to the topic, and after some discussion with several people
off-list, I feel that it is at least worth discussing for the next
version.

Operator overloads has come up as a missing feature in several
discussions on list since the previous proposal was declined. This
includes:

[RFC] [Discussion] Support object type in BCMath [1]

Native decimal scalar support and object types in BcMath [2]

Custom object equality [3]

pipes, scalar objects and on? [4]

[RFC][Discussion] Object can be declared falsifiable [5]

The request to support comparison operators (>, >=, ==, !=, <=, <, <=>)
has come up more frequently, but particularly in discussion around
linear algebra, arbitrary precision mathematics, and dimensional
numbers (such as currency or time), the rest of the operators have also
come up.

Typically, these use cases are themselves very niche, but the
capabilities operator overloads enable would be much more widely used.
From discussion on list, it seems likely that very few libraries would
need to implement operator overloads, but the libraries that do would
be well used and thus MANY devs would be consumers of operator
overloads.

I want to discuss what changes to the previous proposal people would be
seeking, and why. The most contentious design choice of the previous
proposal was undoubtedly the operator keyword and the decision to
make operator overload implementations distinct from normal magic
methods. For some of the voters who voted yes on the previous RFC, this
was a "killer feature" of the proposal, while for some of the voters
who voted no it was the primary reason they were against the feature.

There are also several technical and tangentially related items that
are being worked on that would be necessary for operator overloads (and
were originally included in my implementation of the previous RFC).
This includes:

1. Adding a new opcode for LARGER and LARGER_OR_EQUAL so that operand
   position can be preserved during ALL comparisons.

2. Updating ZEND_UNCOMPARABLE such that it has a value other than -1,
   0, or 1 which are typically reserved during an ordering comparison.

3. Allowing values to be equatable without also being orderable (such
   as with matrices, or complex numbers).

These changes could and should be provided independent of operator
overloads. Gina has been working on a separate RFC which would cover
all three of these issues. You can view the work-in-progress on that
RFC here:
https://github.com/Girgias/php-rfcs/blob/master/comparison-equality-semantics.md

I hope to start off this discussion productively and work towards
improving the previous proposal into something that voters are willing
to pass. To do that, I think these are the things that need to be
discussed in this thread:

I voted in favor of the RFC last time around, and assuming an essentially similar RFC is submitted again will most likely vote in favor again. I do believe this is a useful "surgical" feature; not typically used, but when used, very valuable.

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?

IIRC, the main argument against operator was that it was a new keyword people would need to learn, and tools would need to adapt to understand. That is... a curious argument, to me, as it applies to nearly every new language feature that gets added. We just voted in property hooks and asymmetric visibility. Both introduce new syntax for both users and tooling to adapt to. Both passed by substantial margins.

For me, the main argument in favor of the operator keyword is that it allows us to sidestep a particular challenge: Is the method to override the + operator named __plus() or __add()? Do those words even mean the right thing? Should * be named __times(), __multiply(), or __dotproduct()? Depending on what type of data you're working on, any of those could be accurate, or completely wrong and misleading. Instead writing

operator +(...)

means I know precisely which symbol I'm defining. As a side benefit, we also don't have to think about what visibility means on an operator, which is just kinda weird.

As an extreme example, Python's popular PathLib uses / as a concatenation operator, because it "looks like" a path. A PHP implementation of the same could be something like this:

class Path
{
private array $parts;

public function __construct(string $path) {
$this->parts = array_filter(explode('/', $path));
}

public function __toString() {
return implode('/', $this->parts);
}

// And then one of these:

public function __divide(...) { ... }

// or

operator /(...) { ... }
}

One of those is horribly misleading about what's going on. The other is extremely descriptive.

Now, opponents of operator overloading, or just the operator keyword, would argue that the above is exactly what they want to avoid. For me, that's exactly what I want to enable. At some level, it's just a basic philosophical difference.

Another argument I recall is that the operator syntax makes it "natural" and tempting to extend to user-defined operators, so you could define your own operator+-*&() for an object to do god knows what. I fully agree, there is a risk to doing that. However, that is not what this RFC was, and I presume will be, suggesting: The available operators are a built-in fixed list. If we want to add some new operator that only makes sense for objects (such as a bind operator, something I'd love), that would be its own RFC that we could argue about. And those who don't want user-definable operators can readily vote against any future proposal to do so, while still giving us the benefit of the known operators.

I will also note that, in my research into collections in other languages, providing operator overloads for collections is extremely common, and in practice I find it very ergonomic. We will probably want collections as built in classes for performance anyway (whether using a custom syntax or generics), but I note that as another datapoint where operator overloads make a great deal of sense, but their "standard arithmetic names" would be very misleading. (They often use the boolean & and | operators, too, which results in some really nice and very readable code.)

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?

My sense, which I've written about before, is that there are different "sets" of operators that cluster together. IIRC, I said something like:

A. Comparisons. (<=>, ==, etc.)

B. Arithmetic operators (+, -, *, /).

C. Everything else (concat, etc.)

I personally believe that's the order of importance. If we wanted to just dip our toes into operator overloading, we could do just set A for now. I'm fine with all three groups being approved, as I have uses for all of them. I could see having A be the main vote, and B and C being secondary votes on the same RFC.

3. Do you feel there were any glaring design weaknesses in the previous
   RFC that should be addressed before it is re-proposed?

Only minor things, I think. "OperandPosition" is a very long name to type all the time, even if I can't come up with something better. The operand ordering is kinda weird, but given how much discussion went into it last time I don't have any alternative that isn't either worse or more weird, or both.

The "multiply by -1 for <=>" bit I don't fully understand the point of. The RFC tries to explain, but I don't quite grok it.

For reflection, I'd be inclined to make ReflectionOperator extends ReflectionMethod, rather than an isOperator() method. That is largely stylistic, I suppose, as I am generally a fan of making the type system do the work for us whenever possible.

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?

I was fairly happy with the previous version, so proposing that as-is would have my vote. I would probably oppose including arbitrary symbol overloading at this time.

To me, the most important factors are:

1. It's type-safe, and leverages the type system to "make invalid states unrepresentable" as much as possible. (I'd put the rules around <=> into this category.)

2. It allows me to opt-in piecemeal to just those operators that make sense.

3. The performance overhead compared to using a method is minimal.

4. It is future-compatible with further language evolution, to the extent possible. (The operator keyword helps here.)

I'd love to see this brought up again, and hope there is sufficient interest to do so.

--Larry Garfield

On Sun, Sep 15, 2024 at 12:52 AM Jordan LeDoux jordan.ledoux@gmail.com
wrote:

These changes could and should be provided independent of operator
overloads. Gina has been working on a separate RFC which would cover all
three of these issues. You can view the work-in-progress on that RFC here:
https://github.com/Girgias/php-rfcs/blob/master/comparison-equality-semantics.md

Unrelated topic, sorry for the spam.
I just wanted to point out that interface default methods will play nicely
with the mentioned interfaces: Equatable and Comparable:

interface Equatable {
public function equals(mixed $other): bool;
}
interface Comparable extends Equatable {
public function compare(mixed $other): int;
public function equals(mixed $other): bool {
return $this->compare($other) === 0;
}
}

So that it signals a clear intent of: "what is comparable is also
equatable, and this is the default implementation for it.

Alex

This discussion will use my previous RFC as the starting point for conversation: https://wiki.php.net/rfc/user_defined_operator_overloads

There has been discussion on list recently about revisiting the topic of operator overloads after the previous effort which I proposed was declined. There are a variety of reasons, I think, this is being discussed, both on list and off list.

On behalf of all struggling PHP developers who would like to implement
patterns like Value Objects, with custom equality criterias;
understanding that this is going to be read by quite an amount of
people, I still would like to express my, and perhaps others',
emotional state:

Please make it happen guys 😭🙏!!111

I also agree that == comparisons should be prioritized if only a
subset of operators is to be implemented at once. The arithmetic is
also useful for stuff like GMP, but the niche in PHP is smaller for
that use case.

Regards,
Illia / someniatko

I want to discuss what changes to the previous proposal people would
be seeking, and why. The most contentious design choice of the
previous proposal was undoubtedly the operator keyword and the
decision to make operator overload implementations distinct from
normal magic methods. For some of the voters who voted yes on the
previous RFC, this was a "killer feature" of the proposal, while for
some of the voters who voted no it was the primary reason they were
against the feature.

I am still generally in favour, just like I was on the previous
iteration. And yes, I would say having the "operator" keyword was a
"killer feature" for me.

I hope to start off this discussion productively and work towards
improving the previous proposal into something that voters are willing
to pass. To do that, I think these are the things that need to be
discussed in this thread:

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?

Yes. Making it clear what happens is useful.

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?

I'm not too worried, but usually smaller RFCs have a larger chance of
being accepted.

cheers,
Derick

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?

I think there are two fundamental decisions which inform a lot of the
rest of the design:

1. Are we over-riding operators or operations? That is, is the user
   saying "this is what happens when you put a + symbol between two Foo
   objects", or "this is what happens when you add two Foo objects together"?
2. How do we despatch a binary operator to one of its operands? That is,
   given $a + $b, where $a and $b are objects of different classes, how do
   we choose which implementation to run?

One extreme is the "operators are just methods with funny names"
approach: $a + $b is just sugar for $a->operator+($b); $a can do
whatever it likes, but if it doesn't implement the operator, an error
happens. There's no need to indicate reversed operands, no
implementation on $b is never called.

This is simple to implement, and great for users who want to build
concise DSLs; but that degree of freedom is often unpopular.

Towards the other end on question 1, you have defined operations with
expected semantics, return types, relationships between operators, etc.
The previous RFC actually went down this route for comparisons, defining
a single "operator <=>" that actually overloaded all the comparison
operators at once.

I think if we're going down that route, a name like "__compare" or
"interface Comparable { function compare(...) }" makes more sense -
you're not actually saying "this is what happens if you type a
spaceship", you're saying "here's how to compare two objects".

On question 2, there are a few different possibilities.

Despatch based on type:

a) Binary operators are defined globally on specific type pairs, and the
"best" overload chosen from all those currently loaded
b) Slightly more restricted: they are defined as static methods, and the
best overload chosen from the union of those defined on classes A and B
(this is how C# works)
c) Operator overloads are only possible between a class and a
scalar/non-object, or a class and one of its ancestors; the
implementation on the most specific class is used (e.g. if B extends A,
B's implementation will be used)

All of these can be written in a way that guarantees consistency ($a +
$b will always call the same as $b + $a). Both (a) and (b) would be
quite alien to PHP, which doesn't otherwise have multiple despatch, but
(c) is quite tempting as a conservative approach.

Despatch by trial and error:

d) Each class can only define one overload for an operator, but can
specify which types it accepts; if the definition on type A does not
accept instances of B, the definition on type B is attempted
e) Operator overloads all accept "mixed", but the definition on A can
dynamically return a value which causes the definition on B to be
attempted (this is how Python works)
f) Instead of returning a special value, allow throwing a special
exception; can be combined with option (d) by having the system catch
any TypeError
g) As in the previous proposal, the implementation on class B is only
called if no implementation on class A exists

Each of these can be combined with a special case to always prefer
sub-classes; e.g if B extends A, then (new A) + (new B) should call the
implementation on B first, even though it's on the RHS. (I spotted this
in the Python docs, and it seems very sensible.)

Finally, a very quick note on the OperandPosition enum: I think just a
"bool $isReversed" would be fine - the "natural" expansion of "$a+$b" is
"$a->operator+($b, false)"; the "fallback" is "$b->operator+($a, true)"

Regards,

--
Rowan Tommins
[IMSoP]

On Sat, Sep 14, 2024 at 11:51 PM Jordan LeDoux jordan.ledoux@gmail.com
wrote:

Hello internals,

This discussion will use my previous RFC as the starting point for
conversation: https://wiki.php.net/rfc/user_defined_operator_overloads

There has been discussion on list recently about revisiting the topic of
operator overloads after the previous effort which I proposed was declined.
There are a variety of reasons, I think, this is being discussed, both on
list and off list.

1. As time has gone on, more people have come forward with use cases.
   Often they are use cases that have been mentioned before, but it has become
   more clear that these use cases are more common than was suggested
   previously.

2. Several voters, contributors, and participants have had more time
   (years now) to investigate and research some of the related issues, which
   naturally leads to changes in opinion or perspective.

3. PHP has considered and been receptive toward several RFCs since my
   original proposal which update the style of PHP in ways which are congruent
   with the KIND of language that has operator overloads.

I mentioned recently that I would not participate in another operator
overload RFC unless I felt that the views of internals had become more
receptive to the topic, and after some discussion with several people
off-list, I feel that it is at least worth discussing for the next version.

Operator overloads has come up as a missing feature in several discussions
on list since the previous proposal was declined. This includes:

[RFC] [Discussion] Support object type in BCMath 1

Native decimal scalar support and object types in BcMath 2

Custom object equality 3

pipes, scalar objects and on? 4

[RFC][Discussion] Object can be declared falsifiable 5

The request to support comparison operators (>, >=, ==, !=, <=, <, <=>)
has come up more frequently, but particularly in discussion around linear
algebra, arbitrary precision mathematics, and dimensional numbers (such as
currency or time), the rest of the operators have also come up.

Typically, these use cases are themselves very niche, but the capabilities
operator overloads enable would be much more widely used. From discussion
on list, it seems likely that very few libraries would need to implement
operator overloads, but the libraries that do would be well used and thus
MANY devs would be consumers of operator overloads.

I want to discuss what changes to the previous proposal people would be
seeking, and why. The most contentious design choice of the previous
proposal was undoubtedly the operator keyword and the decision to make
operator overload implementations distinct from normal magic methods. For
some of the voters who voted yes on the previous RFC, this was a "killer
feature" of the proposal, while for some of the voters who voted no it was
the primary reason they were against the feature.

There are also several technical and tangentially related items that are
being worked on that would be necessary for operator overloads (and were
originally included in my implementation of the previous RFC). This
includes:

1. Adding a new opcode for LARGER and LARGER_OR_EQUAL so that operand
   position can be preserved during ALL comparisons.

2. Updating ZEND_UNCOMPARABLE such that it has a value other than -1, 0,
   or 1 which are typically reserved during an ordering comparison.

3. Allowing values to be equatable without also being orderable (such as
   with matrices, or complex numbers).

These changes could and should be provided independent of operator
overloads. Gina has been working on a separate RFC which would cover all
three of these issues. You can view the work-in-progress on that RFC here:
https://github.com/Girgias/php-rfcs/blob/master/comparison-equality-semantics.md

I hope to start off this discussion productively and work towards
improving the previous proposal into something that voters are willing to
pass. To do that, I think these are the things that need to be discussed in
this thread:

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?

Jordan

External Links:

I'm not experienced with other languages and overloading, so consider this
reply as me not knowing enough about the subject. Rowan asked an
interesting question: "Are we over-riding operators or operations?"
which made me think about behaviors as a 3rd alternative. Instead of
individual operator overloading, could classes define how they would act as
certain primitives or types that have overloading under the hood? We have
Stringable with __toString, which might not be the best example but
does point in a similar direction. I don't know if this is a direction
worth exploring but wanted to at least bring it up.

interface IntBehavior {
    public function asInt(): int;
}

class PositiveInt implements IntBehavior {
    public readonly int $value;
    public function __construct(int $value) {
        $this->value = max(0, $value);
    }
    public function asInt(): int {
        return $this->value;
    }
}

var_dump(10 + new PositiveInt(5)); // 15
var_dump(new PositiveInt(10) + 15); // 25
var_dump(new PositiveInt(100) + new PositiveInt(100)); // 200

// leaves it to the developer to do:
$number = new PositiveInt(new PositiveInt(10) + 5);

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.

Hello internals,

This discussion will use my previous RFC as the starting point for
conversation: https://wiki.php.net/rfc/user_defined_operator_overloads

Replying to the top to avoid dragging any particular side discussion into this...

I've seen a few people, both in this thread and previously, make the argument that "operator overloads are only meaningful for math, and seriously no one does fancy math in PHP, so operator overloads are not necessary." This statement is patently false, and I would ask that everyone stop using it as it is simply FUD. I don't mean just the "no one does fancy math in PHP", but "operators are only meaningful for math" is just an ignorant statement.

As someone asked for use cases, here's a few use cases for operator overloads that do not fall into the category of fancy numeric math. Jordan, feel free to borrow any of these verbatim for your next RFC draft if you wish. (I naturally haven't tried running any of them, so forgive any typos or bugs. It's just to get the point across of each use case.)

Pathlib

As I mentioned previously, Python's pathlib uses / to join different path fragments together. In PHP, one could implement such a library very simply with overloads. (A not-late-night implementation would probably be more performant than this, but it's just a POC.)

class Path implements Stringable
{
private array $parts;

public function __construct(?string $path = null) {
$this->parts = array_filter(explode('/', $path ?? ''));
}

public static function fromArray(array $parts): self {
$new = new self();
$new->parts = $parts;
return $new;
}

public function __toString() {
return implode('/', $this->parts);
}

operator /(Path|string $other, OperandPosition $pos): Path {
if ($other instanceof Path) {
$other = (string)$other;
}
$otherParts = array_filter(explode('/', $path));

return match ($pos) {
  OperandPosition::LeftSide => self::fromArray([...$this->parts, ...$otherParts]),
  OperandPosition::RightSide => self::fromArray([...$otherParts, ...$this->parts]),
};

}
}

$p = new Path('/foo/bar');
$p2 = $p / 'beep' / 'narf/poink';

Collections

In my research into collections in other languages, I found it was extremely common for collections to have operator overloads on them. Rather than repeat it here, I will just link to my results and recommendations for what operators would make sense for what operation:

https://github.com/Crell/php-rfcs/blob/master/collections/research-notes.md#operator-based-operations

Enum sets

Ideally, we would just use generic collections for this directly. However, even without generics, bitwise overloads would allow for this to be implemented fairly easily for a given enum. (Again, a smarter implementation is likely possible with actual effort.)

enum Perm {
case Read;
case Write;
case Exec;
}

class Permissions {
private array $cases = [];

public function __construct(Perm ...$perms) {
foreach ($perms as $case) {
$this->cases[$case->name] = 1;
}
}

operator +(Perm $other, OperandPosition $pos): Permissions {
$new = clone($this);
$new->cases[$other->name] = 1;
return $new;
}

operator +(Perm $other, OperandPosition $pos): Permissions {
$new = clone($this);
unset($new->cases[$other->name]);
return $new;
}

operator |(Permissions $other, OperandPosition $pos): Permissions {
$new = clone($this);
foreach ($other->cases as $caseName => $v) {
$new->cases[$caseName] = 1;
}
return $new;
}

operator &(Permission $other, OperandPosition $pos): Permissions {
$new = new self();
$new->cases = array_key_intersect($this->cases, $other->cases);
return $new;
}

// Not sure what operator makes sense here, so punting as this is just an example.
public function has(Perm $p): bool {
return array_key_exists($this->cases, $p->name);
}
}

$p = new Permissions(Perm::Read);
$p2 = $p + Perm::Exec;
$p3 = $p2 | new Permissions(Perm::Write);
$p3 -= Perm::Exec;
$p3->has(Perm::Read);

Function composition

I have long argued that PHP needs both a pipe operator and a function composition operator. It wouldn't be ideal, but something like this is possible. (Ideally we'd use the string concat operator here, but the RFC doesn't show it. It would be a trivial change to use instead.)

class Composed {
/** @var \Closure[] */
private array $steps = [];

public function __construct(?\Closure $c = null) {
$this->steps[] = $c;
}

private static function fromList(array $cs): self {
$new = new self();
$new->steps = $cs;
return $new;
}

public function __invoke(mixed $arg): mixed {
foreach ($this->steps as $step) {
$arg = $step($arg);
}
return $arg;
}

operator +(\Closure $other, OperandPosition $pos): self {
return match ($pos) {
OperandPosition::LeftSide => self::fromArray([...$this->steps, $other]),
OperandPosition::RightSide => self::fromArray([$other, ...$this->steps]),
};
}
}

$fun = new Composed()

• someFunc(...)
• $obj->someMethod(...)
• fn(string $a) => $a . ' (archived)'
• strlen(...);

$fun($input); // Calls each closure in turn.

Note that there are a half-dozen libraries in the wild that do something akin to this, just much more clumsily, including in Laravel. The code above would be vastly simpler and easier to maintain and debug.

Units

Others have mentioned this before, but to make clear what it could look like:

abstract readonly class MetricDistance implements MetricDistance {
protected int $factor = 1;

public function __construct(private int $length) {}

public function +(MetricDistance $other, OperandPos $pos): self {
return new self(floor(($this->length * $this->factor + $other->length * $other->factor)/$this->factor));
}

public function -(MetricDistance $other, OperandPos $pos): self {
return match ($pos) {
OperandPosition::LeftSide => new self(floor(($this->length * $this->factor - $other->length * $other->factor)/$this->factor)),
OperandPosition::RightSide => new self(floor($other->length * $other->factor - $this->length * $this->factor)/$this->factor)),
};
}

public function __toString(): string {
return $this->length;
}
}

readonly class Meters extends MetricDistance {
protected int $factor = 1;
}

readonly class Kilometers extends MetricDistance {
protected int $factor = 1000;
}

$m1 = new Meters(500);
$k1 = new Kilometers(3);
$m1 += $k1;
print $m1; // prints 3500

$m1 + 12; // Error. 12 what?

There's likely a bug in the above somewhere, but it's late and it still gets the point across for now.

(Side note: The previous RFC supported abstract operator declarations, but not declarations on interfaces. That seems necessary for completeness.)

Date and time

DateTimeImmutable and DateInterval already do this, and they're not "fancy math."

I consider all of the above to be reasonable, viable, and useful applications of operator overloading, none of which are fancy or esoteric math cases. Others may dislike them, stylistically. That's a subjective question, so opinions can differ. But the viability of the above cases is not disputable, so the claim that operator overloading is too niche to be worth it is, I would argue, demonstrably false.

--Larry Garfield

Hello internals,

This discussion will use my previous RFC as the starting point for conversation:https://wiki.php.net/rfc/user_defined_operator_overloads

There has been discussion on list recently about revisiting the topic of operator overloads after the previous effort which I proposed was declined. There are a variety of reasons, I think, this is being discussed, both on list and off list.

1. As time has gone on, more people have come forward with use cases. Often they are use cases that have been mentioned before, but it has become more clear that these use cases are more common than was suggested previously.

2. Several voters, contributors, and participants have had more time (years now) to investigate and research some of the related issues, which naturally leads to changes in opinion or perspective.

3. PHP has considered and been receptive toward several RFCs since my original proposal which update the style of PHP in ways which are congruent with the KIND of language that has operator overloads.

I mentioned recently that I would not participate in another operator overload RFC unless I felt that the views of internals had become more receptive to the topic, and after some discussion with several people off-list, I feel that it is at least worth discussing for the next version.

Operator overloads has come up as a missing feature in several discussions on list since the previous proposal was declined. This includes:

[RFC] [Discussion] Support object type in BCMath 1

Native decimal scalar support and object types in BcMath 2

Custom object equality 3

pipes, scalar objects and on? 4

[RFC][Discussion] Object can be declared falsifiable 5

The request to support comparison operators (>, >=, ==, !=, <=, <, <=>) has come up more frequently, but particularly in discussion around linear algebra, arbitrary precision mathematics, and dimensional numbers (such as currency or time), the rest of the operators have also come up.

Typically, these use cases are themselves very niche, but the capabilities operator overloads enable would be much more widely used. From discussion on list, it seems likely that very few libraries would need to implement operator overloads, but the libraries that do would be well used and thus MANY devs would be consumers of operator overloads.

I want to discuss what changes to the previous proposal people would be seeking, and why. The most contentious design choice of the previous proposal was undoubtedly the operator keyword and the decision to make operator overload implementations distinct from normal magic methods. For some of the voters who voted yes on the previous RFC, this was a "killer feature" of the proposal, while for some of the voters who voted no it was the primary reason they were against the feature.

There are also several technical and tangentially related items that are being worked on that would be necessary for operator overloads (and were originally included in my implementation of the previous RFC). This includes:

1. Adding a new opcode for LARGER and LARGER_OR_EQUAL so that operand position can be preserved during ALL comparisons.

2. Updating ZEND_UNCOMPARABLE such that it has a value other than -1, 0, or 1 which are typically reserved during an ordering comparison.

3. Allowing values to be equatable without also being orderable (such as with matrices, or complex numbers).

These changes could and should be provided independent of operator overloads. Gina has been working on a separate RFC which would cover all three of these issues. You can view the work-in-progress on that RFC here: https://github.com/Girgias/php-rfcs/blob/master/comparison-equality-semantics.md

I hope to start off this discussion productively and work towards improving the previous proposal into something that voters are willing to pass. To do that, I think these are the things that need to be discussed in this thread:

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?

Jordan

External Links:

I haven't read much of the discussion, because it is at 40 emails long already.

However, as someone that used to be vehemently against operator overloading (because of C++ whackyness) and has come around I will mention the following.
PHP supports operator overloading already, be that overloading the array access notation via the ArrayAccess interface, overloading comparison operators since at least PHP 5.3, or overloading binary operations since PHP 5.6 via the Internal operator overloading and GMP improvements RFC. 1
Yes the latter two may be reserved to internal classes, but it is extremely easy to expose this internal mechanism to userland by using a custom extension.
Therefore, userland has access to this capability in PHP today just in a very clunky way.

Will exposing this capability in an "easier" fashion to userland lead to people abusing it? Possibly, but PHP doesn't need the help of userland for abusing operators.
Indeed the + operator works with arrays, and is not commutative, which is highly surprising.
This leads to a rather insane situation where the engine does not assume + is always commutative but does so for *, something which makes no sense as multiplication or product operations are (in the grand scheme of mathematics) rarely commutative.
So if an extension wants to provide operator overloading for vectors or matrices the current situation encourages using + for multiplication, and * for addition, which is bonkers.

I am also very much in favour of using the sigils rather than names for overloading the operators.
But if people do not want the operator keyword, or have some aspects be exposed via interfaces (like Comparable/Ordable) than we should find a way to be able to write:
public static function ==(MandatoryType $left, MandatoryType $right) {}
public static function <=>(MandatoryType $left, MandatoryType $right) {}

The other thing, which is different from the previous proposal, and becomes more relevant if we use functions, is that I think that they should be static methods that take the left and right operands instead of assuming it is on the left and/or needing a boolean argument indicating if it is on the left or not.

I am still planing on going through an overhaul of PHP comparison semantics, as indicated by my existing draft, but this might take a while.

Best regards,

Gina P. Banyard

1 https://wiki.php.net/rfc/operator_overloading_gmp

Yes, if constraints of the nature I propose below are adopted.

The biggest problem I have with operator overloads is that — once added —
all code could potentially be "infected" with operator overloads. However,
if the developer using an operator overload could instead opt-in to using
them, in context, then I would flip my opinion and I would begin to support
them.

What might opt-in look like? I propose two (2) mechanisms of which each
would be useful for different use-cases. As such I do not see these two as
competing but instead would expect adding both to be preferable:

1. Add a pair of sigils to enclose any expression that would need to
   support userland operator overloading. This would allow a developer to
   isolate just the expression that needs to use operator overloading. I
   propose {[...]} for this, but feel free to bikeshed sigils. Using an
   example from the RFC, here is what code might look like:

$cnum1 = new ComplexNumber(1, 2);
$cnum2 = new ComplexNumber(3, 4);
$cnum3 = {[ $cnum1 * $cnum2 ]}; // Uses operator operloading
sigils
echo $cnum3->realPart.' + '.$cnum3->imaginaryPart.'i';

2. For when using {[...]} would be annoying because it would be needed
   in so many places, PHP could also add support for an attribute. e.g.
   #[OperatorOverloads(Userland:true)]. This attribute would apply to
   functions, methods, classes, enums, (other?) and indicates that operator
   overloads can be present anywhere in the body of the decorated structure. I
   included Userland:true as an indicator to a reader that this only applies
   to userland operator overloads and that built-in ones like in GMP and
   anywhere else would not need to be opted into, but that parameter could of
   course be dropped if others feel it is not needed. Again, feel free to
   bikeshed attribute name and/or parameters.

#[OperatorOverloads(Userland:true)]
function SprintProductOfTwoComplex(ComplexNumber $cnum1, ComplexNumber
$cnum2)string {
$cnum3 = $cnum1 * $cnum2;
return sprintf("%d + %di", $cnum3->realPart, $cnum3->imaginaryPart);
}

If this approach were included in the RFC then it would also ensure there
is no possibility of BC breakage. BC breakage which would certainly be an
edge case but I can envision it would be possible,e specially where newer
instances incorporating operator overloads are passed to functions that did
not have parameters type hinted but were not intend to be used with
operator overloads resulting in subtle potential breakage.

This argument is also consistent with the argument people had about not
allowing default values to be generically used in calls to the function
function. Their claim was that developers who did not write their code with
the intention of exposing defaults should not have their defaults exposed.
Similarly developers that do not write their code to enable operator
overloads should not be used with userland operator overloads unless they
explicitly allow it, especially as they may not have have tested code with
operator overloads.

Anyway, that is my two cents worth.

TL;DR? I argue that PHP should operator overloads but ONLY if there is a
mechanism that requires the user of expressions that call overloaded
operators to explicitly opt-in to their use.

-Mike

This is interesting, as I've never seen this in any language I researched
as part of operator overloading, and also was never given this feedback or
anything similar by anyone who provided feedback before. My initial
reaction is that I do not understand how this is any better than parameter
typing. If you do not allow any objects into the scope you are using
operators, wouldn't that be the same as the kind of userland control you
are after? Or rather, how would it be substantially worse?

Your second example even includes a function that only accepts a
ComplexNumber object. I presume in your example there that if the
Attribute was removed, the function would just always produce a fatal
error, since that is the behavior of objects when used with *.

What it appears to me your proposal does is transform working operator
overloads into fatal errors if the user-code does not "opt-in". But any
such code would never actually survive long, wouldn't it? Without the
opt-in, these objects would ALWAYS produce fatal errors (which is what
happens now), which would eventually show up in testing, QA, etc. The
developer would realize that they (presumably) were trying to do a math
operation on something they thought was only a numeric type, and then guard
against objects being passed into that context with control statements,
parameter types, etc.

So it seems to me what this ACTUALLY guards against is developers who
inadvertently don't type-check their variables in code where the specific
type is relevant. After one round of testing, all of the code using
operators would either always allow objects and thus overloads, or never
allow objects and thus not use overloads. There shouldn't even be any
existing code that would be affected, since any existing code would need to
currently allow objects in a context where operators are used, which
currently produces a fatal error 100% of the time, (excepting internal
classes which are mostly final anyway, and thus unaffected by this
proposal).

What is the situation where your suggestion is implemented, a developer
does NOT opt-in to overloads, and they avoid unexpected behavior without
having to change their existing code to fix fatal errors? I don't see how
that is possible.

Also, replying into a 3 year old reddit thread I linked to for reference is
not what I intended, however I want to highlight one other thing you
commented there but not here for some reason:

To illustrate my point, imagine if we also allowed control structure
overloads. If we had them we could no longer read code and know that an if
is a branch and a for is a loop; either could be anything valid for any
control structure. Talk about ambiguity!

Indeed. I want to make sure that I have not been ambiguous after reading
this, because I found it somewhat troubling:

I am looking at writing an RFC for specific operators that are finite and
defined within the RFC. I am not proposing something that would allow
control structures to be altered (I don't even think that would be possible
without essentially rewriting the entire Zend Engine specifically to do it).

Operators are not control structures. Operators mutate the value or state
of a variable in a repeatable way, given the input states. There is not
even a generalized mechanism in my RFC for "arbitrary" overloads, and the
compiler was not implemented in a way that is generalized for it either. It
allows only exactly the operators that are part of the RFC, and each are
handled specifically and individually.

Jordan