Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127170
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 22 Apr 2025 15:36:31 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <eb18aa47-b8e3-46bc-9675-ddcd5cadf536@app.fastmail.com>
In-Reply-To: 
 <vGg0HUwcQYHPObu4fCis7JnNYA1s7pNi6XRcMbkYl9p9IFXbBn1yUoQc4nqf-wvWvD61WN1FhkJnZWfRbBIlKWL6Mct2hOlJ2lJMOfAJEAE=@gpb.moe>
References: 
 <vGg0HUwcQYHPObu4fCis7JnNYA1s7pNi6XRcMbkYl9p9IFXbBn1yUoQc4nqf-wvWvD61WN1FhkJnZWfRbBIlKWL6Mct2hOlJ2lJMOfAJEAE=@gpb.moe>
Subject: Re: [PHP-DEV][Pre-RFC] Associated Types
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

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