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