Override static in return types with self in final classes

[rekmixa]

Description

After implementing static types in return methods, I noticed one thing that was illogical, in my opinion.

We have the following code:

<?php

declare(strict_types=1);

interface A
{
    public function method1(): static;
}

abstract class B
{
    abstract public function method2(): static;
}

trait C
{
    abstract public function method3(): static;
}

final class Foo extends B implements A
{
    use C;

    public function method1(): static
    {
        return $this;
    }

    public function method2(): static
    {
        return $this;
    }

    public function method3(): static
    {
        return $this;
    }
}

$foo = new Foo();

var_dump($foo->method1());
var_dump($foo->method2());
var_dump($foo->method3());

It seems to me that in final classes, redefining return types in methods from static to self will not be a violation of covariance, because the final class will never have children. But now it triggers an error Fatal error: Declaration of Foo::method2(): Foo must be compatible with B::method2(): static. What do you think about this?

final class Foo extends B implements A
{
    use C;

    public function method1(): self
    {
        return $this;
    }

    public function method2(): self
    {
        return $this;
    }

    public function method3(): self
    {
        return $this;
    }
}

In addition, the same PHPStorm suggests replacing static types with self types in final classes (if this type is not specified in the prototype).

Below I attach a link to the pull request in which I implemented this logic.

#17724

• There are no changes that break backward compatibility or covariance logic.

[Girgias]

I cannot see anything wrong with this transformation either.

static ⊑ self where static is dependent on the class calling it. If self is final, then the class calling the method is always self as such static = self.

[iluuu1994]

It's sound, but is it necessary? If the child removes final, it will need to migrate back to static. But I don't object.

[Girgias]

The one advantage I could see is for the engine to do this transformation, which could simplify some variance checks and give more robust Reflection information if/when we add isSubTypeOf style methods to reflection if done in tandem with #17755 / #11460

[iluuu1994]

Letting the engine do it would be fine, although it is obviously observable. Might be worth sending a quick e-mail to the list.

[rekmixa]

I added union types support for this feature and wrote additional tests for it. But I don't understand how to add support for this with intersection types) So for now I just added the !intersection check :)

https://github.com/php/php-src/pull/17724/files#diff-16d00017a3ed574cca152e8754246a1424db74e221934eb1c0c2513442882615R575

Maybe someone else can do this?

[rekmixa]

It's sound, but is it necessary? If the child removes final, it will need to migrate back to static. But I don't object.

Yes, there may be some inconvenience with this. But here, in fact, we are talking only about the fact that the language has the ability to replace static with self. This should not be mandatory. For me personally, it would be convenient. I am used to not using the static keyword inside when writing final classes, because it is a little confusing.

[rekmixa]

It's sound, but is it necessary? If the child removes final, it will need to migrate back to static. But I don't object.

It seems to me that using static inside classes always implies that the class can have children. And when static occurs in the final class, it's a bit confusing. So I'd like to see the language provide the ability to replace static with self, because again, it's not a violation of covariance.

[rekmixa]

Letting the engine do it would be fine, although it is obviously observable. Might be worth sending a quick e-mail to the list.

Okay, i'll send

[rekmixa]

https://externals.io/message/126367