Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125239
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 25 Aug 2024 15:57:28 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <68b2f0c0-17e5-4aa4-8706-92f05aca2a95@app.fastmail.com>
In-Reply-To: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net>
References: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net>
Subject: Re: [PHP-DEV] State of Generics and Collections
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Aug 19, 2024, at 12:08 PM, Derick Rethans wrote:
> Hi!
>
> Arnaud, Larry, and I have been working on an article describing the 
> state of generics and collections, and related "experiments".
>
> You can find this article on the PHP Foundation's Blog:
> https://thephp.foundation/blog/2024/08/19/state-of-generics-and-collections/
>
> cheers,
> Derick

To offer my own answers to the questions posed:

* I am against erased generics in the language, on the grounds that we already have them via docblocks and user-space tooling.  Pushing the entire ecosystem to move that existing syntax into another existing syntax that doesn't really offer the user anything new is not worth the effort or disruption it would cause.  Reified, enforced generics would be worth the hassle.

* Even if I could be convinced of erased generics as a stop-gap, I would want to see a official, supported, first-party support for validating them in the PHP linter command, or similar.  If that is surprisingly hard (it may be), then that would preclude erased generics for me.

* I am open to punting on type inference, or having only limited type inference for now (eg, leaving out union types).  Primarily, doing so would be forward-compatible.  Saying for now that you must type `foo<A>(new A())` even if it's redundant doesn't preclude the language in the future allowing `foo(new A())` that figures out the generic type for you, and the explicit code would still continue to work indefinitely.  So this seems like an area that is safe to allow to grow in the future.

* I am also OK if there is a (small) performance hit for generic code, or for especially esoteric generic code.  Eg, if `new Foo<A>` has a 1% performance hit vs `new Foo`, and `new Foo<A|B>` has a 5% performance hit, I can live with that.  `new Foo<A|B>` is a zany edge case anyway, so if that costs a bit more, I'm fine.  It would not be fine if adding generics made `new Foo` 30% slower, or if `new Foo<A>` was 30% slower than the non-generic version.

* My sense at the moment is that in/out markers for variance would not be a blocker, so I'd prefer to include those from the start.  That's caveated on them not being a blocker; mainly I want to make sure we ensure they can be done without breaking things in the future, and I suspect the difference between "make sure we can do it" and "just do it" is small.  (I could be wrong on that, of course.)

* I feel the same about `class Foo<A extends Something>` (Foo is generic over A, but A must implement the Something interface): We should make sure it's doable, and I suspect verifying that is the same as just doing it, so let's just do it.  But if we can verify but it will be a lot more work to do, then we could postpone that.

* I could deal with the custom collection syntax, but I'd much rather have real reified generics and then build on top of that.  That would be better for everyone.  I'm willing to wait for it.  (That gives me more time to design collections anyway. :-) )

--Larry Garfield