Hi internals,
I am not a voter, so please treat this only as feedback from a long-time
PHP user and backend/application architect.
I am aware that voting is already open for the Bound-Erased Generic Types
RFC. I am not writing to ask anyone to vote yes or no on the current RFC.
Rather, I would like to ask that PHP keeps a clear and credible path
toward generics after this vote, regardless of the outcome.
From a userland perspective, the need for generics is real. In large PHP
codebases, generic-like contracts already exist everywhere: repositories,
collections, serializers, DTO mappers, dependency injection containers,
event buses, pipelines, result/either types, iterators, hydrators, and
framework extension points.
Today, most of these contracts are expressed through PHPDoc and interpreted
by static analyzers, IDEs, and framework-specific tooling. That has allowed
the ecosystem to move forward, but it also means that one of the most
important parts of the program's type model is outside the language itself.
At the same time, I think the concerns about trust are valid. Native PHP
type declarations currently have a strong expectation attached to them:
when a developer sees a parameter type, return type, or property type in
PHP syntax, they can assume PHP itself enforces it.
If generic syntax weakens that mental model, PHP may gain nicer syntax but
lose some clarity in its type system. I do not think that would be a good
trade-off.
That suggests to me that the most important question is not only "erased
vs reified", but rather:
What kind of type information is this, and who is responsible for enforcing
it?
I would like PHP to have an explicit long-term type model with at least
these categories:
-
Runtime-enforced types, as PHP has today.
-
Compile-time or class-loading-time parametric constraints, especially
for inheritance, interfaces, abstract classes, method signatures, and
property types where this is possible. -
Tooling metadata, useful for static analyzers, IDEs, Reflection-based
frameworks, and code generation, but explicitly not guaranteed by the
runtime.
If PHP adopts erased or partially-erased generics, I think the language
should make this distinction very explicit in documentation, Reflection,
and diagnostics. A developer should be able to tell whether a generic type
is enforced by PHP itself, validated during class loading or inheritance
checks, or merely preserved as structured metadata for tools.
As a possible path forward, I would personally prefer a smaller enforceable
subset first, even if it does not cover every use case that userland wants.
For example:
- Generic interfaces first.
- Generic abstract classes next.
- Concrete classes implementing or extending them should bind type
parameters, unless PHP explicitly supports keeping those declarations
generic. - Substituted method signatures, return types, parameter types, and
property types should be checked by PHP where possible. - Reflection should expose structured generic metadata in a stable way.
- Generic "new", generic functions, complex inference, generic compound
types, and runtime reification can remain future work. - Object-based collections can be built on top of that model before trying
to solve typed arrays.
This would not give PHP full generics immediately, but it would give the
ecosystem a trustworthy foundation. It would also let frameworks and
libraries start replacing PHPDoc templates with native declarations in the
places where there is an actual PHP-level contract behind them.
I believe this is important for more than syntax. A native and trustworthy
generic model would help static analysis, IDEs, framework design,
Reflection-based tooling, code generation, and potentially future optimizer
or compilation work. Without such a model, PHP can still continue to
improve, but a large part of its type information will remain fragmented
across PHPDoc conventions and external tools.
If the current RFC fails, I hope it is not interpreted as "PHP does not
want generics." I think a more useful interpretation would be that PHP
needs a generics roadmap with a clearer trust and enforcement model.
If the current RFC passes, I hope the same concern is still addressed:
the language should document very clearly which parts are enforced by PHP,
which parts are checked only by static analyzers, and which future steps
are expected to close the remaining gaps.
My main request is therefore:
Please do not let the generics discussion remain a binary choice between
"full reified generics now" and "PHPDoc forever."
A smaller, enforceable, explicitly staged model would already be a major
improvement for large PHP systems, and it would preserve trust in PHP's
native type syntax.
Thank you for all the work that has gone into this RFC and the discussion.
Regards,
<wheakerd