On Tue, Apr 22, 2025, at 8:37 AM, Gina P. Banyard wrote:
> 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
If we make this work, I believe this solves the use cases for `never` far
better.
As I noted off-list (just putting it on record), if we're confident that the
generic-style syntax won't interfere with future work on generics, I'd prefer
that style. If it would cause issues, I'd favor the separate `type` syntax or
something similar, but with an explicit rather than implicit declaration of
what T should be.
This would also effectively replace the custom syntax that Derick and I were
considering for typed Collections a while back. A more generic solution like
this would be superior either way.
--Larry Garfield
