On Thu, 12 Mar 2020 at 08:31, Jan Böhmer <jan.h.boeh...@gmx.de> wrote:
> On 11.03.2020 at 10:50, Christoph M. Becker wrote:
> > On 11.03.2020 at 10:22, Nikita Popov wrote:
> >> Does anyone else have thoughts on the ability to specify the supported
> >> types in the signature?
> > I agree that we should not introduce (this special case of) overloaded
> > functions.
>
> I have thought about this the last days, and I agree with you. Therefore
> I have removed this feature from the RFC.
>
I've been thinking about it as well, and am not sure what happens _without_
it in a case like this:
# initial class, only overloads + on instances of itself
class A {
public static function __add(A $lhs, A $rhs) {
// ...
}
}
# in some third-party library
class B {
public static function __add(A|B $lhs, A|B $rhs) {
// ...
}
}
$a = new A;
$b = new B;
var_dump($b + $a); # calls B::__add($b, $a); OK
var_dump($a + $b); # calls A::__add($a, $b), which is a TypeError
If the engine doesn't catch the TypeError, it will never try B::__add($a,
$b) in the second case, so presumably the TypeError will just be thrown to
the user, which doesn't seem very helpful.
Perhaps the simplest solution is to have a restriction that the operator
overloads _must not_ specify types in their signature?
Regards,
--
Rowan Tommins
[IMSoP]
