On 5/12/26 14:41, Rowan Tommins [IMSoP] wrote:
On 12 May 2026 13:01:44 BST, Seifeddine Gmati<[email protected]> wrote:
The audience for native generics is the same audience that already
uses docblock generics, which is the same audience that already runs
SA.
This is an assumption that a lot of your reasoning seems to be based on, and as
I've said already, I think it's a false assumption.
As soon as PHP ships native syntax for generics, an entirely new set of users
will hear about it and try to use it. Their experience is going to be shaped by
what *PHP itself* does with that new syntax.
I would also argue that the flipside applies: if the audience for the feature
really is existing users of third-party SA tools, then it shouldn't be shipped
as part of php-src. The language should only provide the building blocks for
those tools to work with - and attributes seem perfectly suited here.
It's not the job of this list to create standards for what attributes
third-party tools support.
Rowan Tommins
[IMSoP]
What is true for I guess every PHP developer is that they are using a
production and development environment, with a different config in each
environment. Now I am not particularly fond of adding more configuration
settings, but maybe in this case a /generics_mode = erased |
bound-erased | reified/ could help to ship generics now.
As I understand the discussion on generics, the problem with reified
generics, besides the fact there is no implementation at the moment,
would be performance. My solution to this would be to */teach/*, from
the start, not to use reified generics in production. Set the default of
the setting to erased or bound-erased and suggest people to enable
reified in development only. This is where good documentation and
community effort would be vital to teach this entirely new set of users
how to deal with this language feature. You would then develop in a more
strict environment than in production. It is not that this new to
developers. Developers have been transpiling their strict development
typescript and ES6 code to loose/erased JS for at least a decade now.
They have able to teach that, why would PHP not be able to teach their
decisions?
Anyway, until we have reified generics, performant or not, behind a
setting or not, I think that by teaching this new set of users what
bound-erased means and does, why it is there, by explaining which
direction the language is going, I would very much welcome bound-erased
generics. But I believe there would also have to be some kind of
consensus on the direction after bound-erased generics. That is I guess
the hardest part of this RFC. I wish Seifeddine good luck in going forward.
Regards,
Frederik Bosch
Maintainer of MoneyPHP
