Hi Nicolas, The "SA tools drop legacy docblock support immediately" scenario isn't going to happen on the timeline you're worried about. What's more likely is a multi-year deprecation curve: tools will fully support docblock syntax for years after native generics land, then gradually stop adding *new* features to the docblock side (e.g., if a future RFC adds lower bounds or where constraints tools will support it natively but won't try to retrofit it into docblock syntax), and only after the ecosystem has clearly moved would full docblock support actually deprecate.
I can speak for Mago: we won't drop docblock generic support for at least several years after native generics ship, because we need to keep supporting PHP versions earlier than the one this RFC lands in anyway. PHPStan and Psalm are in the same position: they each support a wide range of PHP versions. Dropping docblock generics would mean cutting off users on those older versions entirely, which I presume none of the maintainers want to do. The timeline math also helps. If this RFC ships in PHP 8.6, Symfony 9.1 in May 2028 would be the natural place to bump the minimum to 8.6, that's two years from now. And SA tools would most likely support docblock generics for even longer. the long-tail Symfony/Laravel/Doctrine projects would already be on PHP versions that support native syntax, and the migration would be available rather than required. The concern that contributor pull requests adding native generics before the project is ready will put pressure on maintainers is real, but it mirrors the shape of every previous PHP feature. Readonly properties, enums, named arguments, FCCs, etc. all of these created the same dynamic, which frameworks worked out using version constraints (`composer.json` `"php": ">=8.0"`), conditional code, and policy decisions about when to bump minimums. Native generics don't introduce a new shape of problem; they fit the existing one. On the preprocessor idea: I think the same concerns that ruled out userland generics preprocessors in the RFC's "Userland preprocessors" section apply here. Composer plugins can't reach the IDE, editor, debugger, profiler, test runner, or CI, the boundaries where developers actually work. A preprocessor that erases native generics before execution on older PHP would solve the runtime story but not the tooling story; SA tools, IDEs, and everything else still see the native syntax and need to handle it. So even with a userland preprocessor, projects that want native syntax in source still need their toolchain to support native generics. That said, if Symfony specifically needs a preprocessor that strips native generics for runtime execution on older PHP versions, I'd genuinely be willing to write one. Mago already has the parser, the formatter, and the AST-rewriting infrastructure to make this fairly straightforward; it's a weekend project, not a research one. Happy to do it if it actually unblocks adoption for Symfony. Just say the word. I don't think this warrants baking adoption concerns into the RFC text directly. The deprecation curve is going to be slow regardless of what the RFC says, and writing migration guidance into the RFC pre-commits to specific timelines that the ecosystem will resolve organically. If it would be useful, I can write a separate migration-guide blog post after the RFC settles, but I'd rather not freeze guidance into the spec. Cheers, Seif.
