Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126737
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 13 Mar 2025 11:07:28 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <5ba3fedf-162f-425b-b5f6-01d2d1b9fcaf@app.fastmail.com>
In-Reply-To: <b3d325f0f0444cd68ce2a9cd8cc4e12e@bastelstu.be>
References: 
 <CALaXqqRWL8ygMGoA5xnMtt7w6rE-5WJJZ5P9oiO3vHgqvod=Fw@mail.gmail.com>
 <3e35cd25-c851-4ecc-8a1b-102dadb226e5@app.fastmail.com>
 <b3d325f0f0444cd68ce2a9cd8cc4e12e@bastelstu.be>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Never parameters
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Mar 13, 2025, at 10:35 AM, Tim D=C3=BCsterhus wrote:
> Hi
>
> Am 2025-03-11 22:45, schrieb Larry Garfield:
>> We should not block this kind of improvement on the hope of generics.=
 =20
>> Worst case, we have this plus generics so you have options, how=20
>> terrible.
>
> In this case, I agree. This is an obvious addition to the type system=20
> that uses the existing infrastructure of the type system.
>
> But generally speaking, having too many options is not a good thing. I=
t=20
> makes the language larger and more complex to learn, requires=20
> documentation effort, support by IDEs and static analyzers and similar=20
> things.

It's definitely a balancing act, yes.  TIMTOWTDI definitely has downside=
s, but at the same time, having multiple ways to accomplish the same goa=
l isn't inherently wrong, unless they conflict with each other in some w=
ay.

>> Rust-style associated types would probably work as well.  I'd be fine=20
>> with that approach, too.  One could argue they're more valuable as a=20
>> sort of "junior generics," but absent anyone able and willing to=20
>> implement them, again, worst-case we end up with options in the futur=
e.
>
> =E2=80=A6 so for associated types, I do not necessarily agree. They se=
em to be a=20
> strict subset of the functionality enabled by generics, or the=20
> functionality enabled by type aliases combined with =E2=80=9Cinner cla=
sses /=20
> inner types=E2=80=9D. Since introducing associated types would bring e=
ntirely=20
> new syntax and semantics to the language, it is less obvious to me tha=
t=20
> they are a useful (intermediate) addition to the language.

The counter argument here is that a number of languages (like Rust) have=
 both generics and associated types, so they can coexist and serve sligh=
tly different use cases.  I have not used Rust enough to have an opinion=
 on how and when to use one or the other, but having one doesn't seem to=
 impede the other.

From my (admittedly limited) understanding, associated types sounds rath=
er like the "inheritance only" pseudo-generics that Derick had proposed =
for collections last year, in a more general form.  (cf: https://thephp.=
foundation/blog/2024/08/19/state-of-generics-and-collections/#collection=
s)

--Larry Garfield