Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125170
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 23 Aug 2024 16:06:18 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <7c617909-c019-4a3d-bee9-8e4b0f949acf@app.fastmail.com>
In-Reply-To: <f1e1c68e-104e-4d63-bcb9-94ed92be3649@app.fastmail.com>
References: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net>
 <CADZ9LSXN-_oSUumwXmka7xgEy9PsEjUn+O4YGPP-2QPwyaB5_g@mail.gmail.com>
 <e69928c7-a471-4e00-878e-8bbda4d49c4f@app.fastmail.com>
 <CA+hqhpfSVqH3V-J7BQdg+G2=9msSP=pwONroP=YehcJzCGJ+=A@mail.gmail.com>
 <f1e1c68e-104e-4d63-bcb9-94ed92be3649@app.fastmail.com>
Subject: Re: [PHP-DEV] State of Generics and Collections
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Aug 23, 2024, at 1:38 PM, Rob Landers wrote:
> On Fri, Aug 23, 2024, at 20:27, Bruce Weirdan wrote:
>> On Fri, Aug 23, 2024 at 4:27=E2=80=AFPM Larry Garfield <larry@garfiel=
dtech.com> wrote:
>>> Moving those definitions to attributes is certainly possible, though=
 AFAIK both the PHPStan and Psalm devs have expressed zero interest in i=
t.
>>> Part of the challenge is that such an approach will either still inv=
olve string parsing,
>>=20
>> That's not really a challenge and would help somewhat with the curren=
t status quo where we have to guess where the type ends and the textual =
part of the comment begins. But it gets ugly for any type that has to in=
clude quotes (literal strings, array keys, etc). Technically one can use=
 nowdocs, but it's not much better:  https://3v4l.org/4hpte
>> =20
>>> or will involve a lot of deeply nested attribute classes.=20
>>=20
>> Yeah, that would look like Lisp's S-exprs, but much worse - which, in=
 my opinion, would harm adoption.
>>=20
>> All in all, in my opinion attribute-based solutions are less ergonomi=
c than what we already have now in docblocks.
>>=20
>> --
>>   Best regards,
>>       Bruce Weirdan                                     mailto:weirda=
n@gmail.com
>
> Thank you Larry for expressing some of the problems. Is there any=20
> reason nesting has to be supported out of the gate? Think about type=20
> hints. It started with some basic functionality and then grew over=20
> time. There is no reason we have to have a new kitchen sink, oven,=20
> dishwasher and stove when all we want is a new refrigerator.=20
>
> =E2=80=94 Rob

While I understand the temptation to "just do part of it", which comes u=
p very often, I must reiterate once again that can backfire badly.  That=
 is only sensible when:

1. There's a very clear picture to get from A->Z.
2. The implementation of C and D cannot interfere with the design or imp=
lementation of J or K.
3. The steps along the way offer clear self-contained benefits, such tha=
t if nothing else happens, it's still a "complete" system and a win.
4. The part being put off to later isn't just putting off the "hard part=
".

In practice, the level at which you get all four is quite coarse, much c=
oarser than it seems most people on this list think.

Examples of where we have done that:

* Enums.  The initial Enum RFC is part one of at least 3 steps.  Step 2 =
is pattern matching, Step 3 is ADTs/tagged unions.  Those are still comi=
ng, but all three were spec'ed out in advance (1), we're fairly confiden=
t that the enum design will play nice with tagged unions (2), and enums =
step 1 has very clearly been hugely positive for the language (3, 4).

* Property hooks and aviz.  These were designed together.  They were ori=
ginally a single planning document, way back in Nikita's original RFC.  =
After effectively doing all the design work of both together, we split u=
p the implementations to make them easier.  Hooks was still a large RFC,=
 but that was after we split things up.  That meant we had a clear pictu=
re of how the two would fit together (1, 2), either RFC on its own would=
 have been beneficial to the language even if they're better together (2=
, 3), and both were substantial tasks in themselves (4).

* Gina's ongoing campaign to make PHP's type juggling have some passing =
resemblance to logic.

With generics, the syntax isn't the hard part.  The hard part is type in=
ference, or accepting that generic-using code will just be extraordinari=
ly verbose and clumsy.  There is (as I understand from Arnaud, who again=
 can correct me if I'm wrong) not a huge amount of difference in effort =
between supporting only Foo<Bar> and supporting Foo<Bar<Baz>>.  The nest=
ing isn't the hard part.  The hard part is not having to type Foo<Bar> 4=
 times across 2 files every time you do something with generics.  If tha=
t can be resolved satisfactorily (and performantly), then the road map t=
o reified generics is reasonably visible.

So for any intermediate generics implementation, it would need to have a=
 very clear picture to get from that initial state to the final state (w=
ithout the landmines that something like readonly gave us), we'd need to=
 be confident we're not adding any landmines, each step would need to be=
 useful in its own right, and it would have to be breaking up the "hard =
work" into reasonable chunks, not just punting the hard work for later.

Leaving out nested generics doesn't achieve those.

This is also why the dedicated collections work that Derick and I were l=
ooking into has been on pause, because adding a dedicated collections sy=
ntax, and then getting full reified generics later, would lead to a very=
 ugly mess of inconsistency.  Better to wait and try to get full generic=
s first, or confirm once and for all that it's impossible.

Strategies that MIGHT make sense in that framework, and the ones on whic=
h we are specifically requesting feedback, include:

* Type-erased generics, with the expectation that they would become enfo=
rced at some point in the future.  (Though this could lead to lots of "w=
orking" code suddenly not working once the enforcement was turned on.)
* No type inference.  Generics are just very verbose, deal with it.  Typ=
e inference could, potentially, be added later.  (Maybe; it's not guaran=
teed that it could be done effectively, as the writeup discusses).
* Only allow generics over simple types, not union/intersection types.  =
Unlike nested generics, union types do increase the cost of determining =
compatibility considerably, so making them performant is a much bigger c=
hallenge.  Maybe that challenge could be punted for later?  (And if late=
r turns into never, or 10 years from now, is that still an acceptable en=
d-state?)

The acceptability of each of these strategies is what we were hoping to =
determine in feedback to the writeup.

--Larry Garfield