On Mon, May 11, 2026, at 11:25 AM, Seifeddine Gmati wrote:
> Hi Rowan,
>
> I think the core premise is empirically testable, and the test has
> already run: PHP has had generics in docblocks for a decade, used by
> every major framework. If "someone publishes a library with broken
> type information and downstream users get surprised by runtime
> behavior" were a real failure mode, we would see it today, as Laravel,
> Doctrine, Symfony, PSL, and PHPUnit all run on `@template`-annotated
> code and are consumed by millions of downstream applications. The
> failure mode you describe is the one that would occur most under the
> current system, yet it doesn't.
>
> The reason it doesn't is that the people who care about generic type
> information are the same people who run static analysis. The
> intersection of "uses generics" and "doesn't run a static analyzer" is
> approximately empty in practice. Native syntax doesn't change that. It
> just gives current users a better way to express what they mean.
>
> Regarding the second point, the proposed implementation is enforced
> more at compile time than docblocks are. The engine validates:
>
> - Generic parameter declarations: arity cap, bound conformance,
> default-vs-bound, no top-level self-reference, no shadowing.
> - Variance soundness: Covariant parameters cannot appear in input
> positions, contravariant parameters cannot appear in output positions,
> at the declaration site.
> - Inheritance: arity at extends/implements/use, bound conformance with
> bound-on-bound for forwarded parameters, diamond detection, parametric
> LSP into properties/hooks/trait methods/inherited methods.
> - Turbofish at runtime: arity and bounds at every call site that
> supplies type arguments.
>
> Docblocks validate none of this; the engine accepts a docblock that
> says anything. Native syntax is a stricter contract than what the
> ecosystem has today.
>
> Finally, on the "broken code published to Packagist" concern: someone
> can already publish:
>
> ```
> /** Map the given array using the provided callable. */
> function map(array $array, callable $fn): array {
> return [];
> }
> ```
>
> The signature claims to take an array and a callable, returns an
> array. The body returns an empty array regardless. Today, this passes
> every PHP type check, parses without error, runs in production, and is
> technically conformant. Nobody is calling for PHP to ship a [precious
> type system](https://www.youtube.com/watch?v=Ay-gnCqDw9o) with support
> for
> [lifetimes](https://doc.rust-lang.org/rust-by-example/scope/lifetime/explicit.html),
> and [const generic
> parameters](https://doc.rust-lang.org/reference/items/generics.html#r-items.generics.const.usage)
> to prevent it (e.g. `function map<'a, I, O, const SIZE: int>(vec<&'a
> I, SIZE> & ![] $array, fn(&'a I): &'a O $fn): vec<&'a O, SIZE> &
> ![]`). The same logic applies to generics: the contract a user writes
> is the contract a user is responsible for honoring, and PHP's role is
> to provide tools for expressing and checking that contract, not to
> make every conceivable mistake impossible.
>
> The options you listed both close off paths the PHP ecosystem has
> already shown it doesn't want.
>
> Cheers,
> Seifeddine.
Hi Seifeddine.
First off, let me congratulate you on an absolutely superb "stage setting" in
this RFC. :-) The first half (the history and arguments for it) is solid, and
I very much appreciate the level of detail it includes.
That said, I tend to agree with Levi. Erased types are a foot-gun.
> The options you listed both close off paths the PHP ecosystem has
> already shown it doesn't want.
I'm not sure I follow what you're saying here, but it's worth noting that the
two points Levi mentioned have never actually been viable, so saying "the
ecosystem doesn't want it" isn't justified. I strongly suspect that the
associated types work that Gina was (and still is, AFAIK) working on would be
well-received and widely used.
As you note, this RFC is a little more than erased generics; it does provide a
little validation, and reflection support (in addition to a standardized syntax
that's much more understandable than the current de facto standard docblock
syntax). That's not nothing, and is a marginal improvement over the status
quo. The question is whether that is enough of a benefit, and what future
improvements it makes easier/harder.
I'm also not sure we can conclude that
> The intersection of "uses generics" and "doesn't run a static analyzer" is
> approximately empty in practice.
Technically, anyone using Symfony or Laravel is "using generics" in that
Symfony and Laravel have generic doc-types on their code. That doesn't imply
that everyone building a site with Symfony or Laravel is regularly running
PHPStan to verify those, or adding their own doc-types to match it. They
*should* be, but I've worked on teams that were using Laravel and I had to
teach them about PHPStan.
Where this becomes a land-mine is less the production deploys today, but that
future improvements become BC breaks. Technically only BC breaks for sloppy
code, but we've gotten ample flack in the past for "BC breaks only for sloppy
code" (eg, promoting undefined vars/keys to warnings, adding return types to
magic methods/interfaces, etc.). My fear (and I don't know how to quantify how
justified this fear is) is that people who don't use SA tools will write code
on top of someone else's generic code, not care that their types are buggy, not
notice, and then we start enforcing it in the future and their code breaks.
I wouldn't want to have a generics-version of #[ReturnTypeWillChange].
A firm and explicitly documented agreement that "if your types are wrong,
that's not covered by BC, so we don't care if it breaks on you later" would be
an option; not a popular option, perhaps, but an option. :-)
Another option, if we want to take the stance that SA is The Solution(tm) to
generics, is to ship an actual first-party SA tool with PHP. Probably not as
robust or pedantic as PHPStan/Psalm/Mago, but at the very least an enhanced
alternative to the existing lint support, to catch things like type mismatches,
generics errors, etc. Yes, I realize this opens up a whole other can of worms,
but generics always opens a can of worms.
I think the associated types enforcement could absolutely be done at the same
time as the erased-for-callsite part. But if we do erased, does that make
adding associated types (basically "declaration enforcement") in the future
harder? Either technically or politically? If so, then that's a problem. If
we set up the processes (both technical and political) to ensure that it is not
harder to add, then we're in a much better position.
So for me to vote in favor of this RFC, we would need to have *some* degree of
first-party enforcement, if for no other reason so that we can improve that
enforcement (whether runtime or otherwise) in the future, bit by bit. "PHP
ships with what you need to write valid PHP" is a good rule to have. We can
(and assuredly will) debate what that means in practice.
As to the RFC details itself:
Syntax notes:
- I agree with Bob that the +/- syntax is very confusing. I would much rather
use in/out, as seen in Kotlin and C#, which are both vastly more
self-documenting and match what some of our peer languages are doing. As Bob
notes, this can be done without completely claiming the "in" and "out" keywords.
- An interesting quirk I found in my previous research[1] is that languages
that use : for inheritance use : for bounding generics. Languages that use
"extends" for inheritance also use "extends" for bounding generics. PHP uses
"extends", so that pattern would suggest we use "class Box<T extends FooBar>"
rather than :. That's longer, though. I'm not sure how I feel here; we
certainly don't have to use the same keyword in both places, but it could be
expected. I mention it mainly so that we can have that discussion and make a
deliberate, informed decision.
Other notes:
- I am completely OK with skipping typed arrays at this point. In practice I'd
rather build objects with nice operator overrides directly into the stdlib.
(See my previous investigation[2] on the subject.)
- I fully expect "turbofish" to result in all kinds of slide shenanigans at
conferences. At least on my slides. :-)
- What would a turbofish on a static call look like? self::<Bar>foo(1) or
self::::<Bar>foo(1)? The RFC should specify.
- I'd be completely OK with lowering the argument cap from 127, too. Like, if
you have more than 4 then you're probably doing something very wrong already.
:-) Reserving more space there seems fine.
- Why is ReflectionGenericVariance backed? I don't see what the ints add.
- The "What is/isn't enforced" section could really use examples. A lot of it
is hard for me to follow as it's so abstract. (And thus determine if it's
"enough" enforcement for me to be able to support it.) Same for the
Limitations section. Examples please.
- OK, having read the full RFC, it seems to be sort of "mostly-erased"
generics. There is notably more enforcement than the term "erased" would
imply. (IE, I'd normally expect that term to mean Python-style "they may as
well be comments" types.) I would recommend raising the "what is enforced"
section, or some junior version of it, way up to the top to help set
expectations, because this is an interesting semi-enforced hybrid. I am still
unsure if it's enforced-enough, but I think calling it "erased" (and most
people won't automatically grok what "bound erased means") is doing it a
disservice. It looks like, in practice, basically everything on the
declaration side is enforced; it's just the call side that is unenforced. Is
that an approximately accurate summary?
- I recommend making a bigger deal of the fact that the turbofish being
optional is a BC layer. Having the absence of it default to mixed is a *huge*
deal for making generics adoption smoother. This is an attribute that should
get a lot more attention than the RFC currently gives it.
- If I understand correctly, this RFC would allow for foo(Collection<int> $c)
{}, but wouldn't actually enforce it at runtime. Within the function,
`instanceof Collection` would still work, but there's no `instanceof
Collection<int>` alternative. Am I reading that correctly?
- I don't see an example of how you'd write "the return value is of the class
specified by this string parameter." That's one of the status quo examples you
show, and one that I use rather frequently. Please include an example of that,
or note that it is not supported and what we should do instead.
I think at this point I am still skeptical, but warming to it, and could be
convinced. But more convincing is needed. And lunch, which I think I need
after reading all of this. :-)
Thanks, Seifeddine!
--Larry Garfield
[1] https://github.com/Crell/php-rfcs/blob/master/generics/use-cases.md
[2] https://github.com/Crell/php-rfcs/blob/master/collections/research-notes.md
