Re: [Pre-RFC] Associated Types
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
Thread (4 messages)