Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126736
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 13 Mar 2025 16:35:24 +0100
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Never parameters
In-Reply-To: <3e35cd25-c851-4ecc-8a1b-102dadb226e5@app.fastmail.com>
References: <CALaXqqRWL8ygMGoA5xnMtt7w6rE-5WJJZ5P9oiO3vHgqvod=Fw@mail.gmail.com>
 <3e35cd25-c851-4ecc-8a1b-102dadb226e5@app.fastmail.com>
Message-ID: <b3d325f0f0444cd68ce2a9cd8cc4e12e@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2025-03-11 22:45, schrieb Larry Garfield:
> We should not block this kind of improvement on the hope of generics.  
> Worst case, we have this plus generics so you have options, how 
> terrible.

In this case, I agree. This is an obvious addition to the type system 
that uses the existing infrastructure of the type system.

But generally speaking, having too many options is not a good thing. It 
makes the language larger and more complex to learn, requires 
documentation effort, support by IDEs and static analyzers and similar 
things.

> Rust-style associated types would probably work as well.  I'd be fine 
> with that approach, too.  One could argue they're more valuable as a 
> sort of "junior generics," but absent anyone able and willing to 
> implement them, again, worst-case we end up with options in the future.

… so for associated types, I do not necessarily agree. They seem to be a 
strict subset of the functionality enabled by generics, or the 
functionality enabled by type aliases combined with “inner classes / 
inner types”. Since introducing associated types would bring entirely 
new syntax and semantics to the language, it is less obvious to me that 
they are a useful (intermediate) addition to the language.

Best regards
Tim Düsterhus