Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127165
Date: Tue, 22 Apr 2025 13:37:48 +0000
To: PHP internals <internals@lists.php.net>
Subject: [PHP-DEV][Pre-RFC] Associated Types
Message-ID: <vGg0HUwcQYHPObu4fCis7JnNYA1s7pNi6XRcMbkYl9p9IFXbBn1yUoQc4nqf-wvWvD61WN1FhkJnZWfRbBIlKWL6Mct2hOlJ2lJMOfAJEAE=@gpb.moe>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

Hello internals,

The discussion about allowing never types as parameter types made me think =
about what problem it is truly trying to solve,
which is using the same type as parameters and return values between multip=
le methods of a common interface.

This is normally solved with generics, but as shown generics are hard TM [1=
] and a lot of the complexity resides in allowing the generic type to be se=
t at *use* site of the class with generic parameters.
However, this does not apply to template/generic types on interfaces, as th=
e bound type is determined by the implementing class at compile time.

As such, a few weeks ago, I created a PoC [2] where one can declare a templ=
ate/associated type T on interfaces that require an implementing class uses=
 the same type when specifying T.

The syntax in the PoC is currently:
```
interface I {
    type T : int|string;
    public function foo(T $param): T;
}
class CS implements I {
    public function foo(string $param): string {
        return $param . '!';
    }
}
```

I.e. the associated type is indicated by a "type" keyword, optionally follo=
wed by a colon `:` and a type constraint.
The type corresponding to the associated type is currently "guessed" by the=
 first usage in a concrete class.

Having talked with Arnaud off-list, it seems that using the "usual" generic=
 syntax of (assuming our parser can cope with it):
```
interface I<T : int|string> {
    public function foo(T $param): T;
}
class CS implements I<string> {
    public function foo(string $param): string {
        return $param . '!';
    }
}
```
is possible and would not conflict with any future proposal for generics.

Importantly, this feature would NOT support doing the followings:
- `$o instanceof I<ConcreteType>`
- Using `I<ConcreteType>` in type declarations

Meaning you do not get static type information, similarly to the `never` as=
 parameter type,
but one is guaranteed that there is no funky type variance and incompatibil=
ities between different methods (or parameter and return types of the same =
method) in a concrete implementation of an interface.

Effectively, static analysis tools must either assume T is `mixed`, or hook=
 it into their generic types feature.
Which is what the current status is for various interfaces (e.g. ArrayAcces=
s).

I am intending on getting this feature ready for 8.5, and the reason I brin=
g it up to the list now, without a proper RFC, is to explain my reasoning f=
or why I am voting against the never parameter type RFC. [3]

For any questions, feel free to reply, but please do remember that this is =
still a bit in flux.


Best regards,

Gina P. Banyard

[1] https://thephp.foundation/blog/2024/08/19/state-of-generics-and-collect=
ions/
[2] https://github.com/php/php-src/pull/18260
[3] https://wiki.php.net/rfc/never-parameters-v2