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 multiple
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 set at
*use* site of the class with generic parameters.
However, this does not apply to template/generic types on interfaces, as the
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
template/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 followed
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
incompatibilities 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. ArrayAccess).
I am intending on getting this feature ready for 8.5, and the reason I bring it
up to the list now, without a proper RFC, is to explain my reasoning for 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-collections/
[2] https://github.com/php/php-src/pull/18260
[3] https://wiki.php.net/rfc/never-parameters-v2
