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: 1. Runtime-enforced types, as PHP has today. 2. Compile-time or class-loading-time parametric constraints, especially for inheritance, interfaces, abstract classes, method signatures, and property types where this is possible. 3. 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>
