OTOH, generics getting voted down (for whatever reason) would be... very bad press, both within the community and externally.
I think you’re overstating the external impact. This would have been bad PR a decade ago, but today PHP language evolution is not front of mind for many outside the PHP community.
I believe (from discussions in the list and online) that most of the people who voted it down have done so due to a very clear philosophical objection to partially-erased types. Those people do not want the biggest potential follow-on from this RFC, which is language support for erased generic array<string>, a construct which has existed in docblocks for a couple of decades.
I think it’s useful to have these decisions written in stone.
I don’t believe there’s a better proposal for erased generics than this one. In the future, when someone asks why PHP doesn’t have erased generics, we can point to this vote.
Best wishes,
Matt
at 05:46, Matthew Brown matthewmatthew@gmail.com wrote:
OTOH, generics getting voted down (for whatever reason) would be... very bad press, both within the community and externally.
I think you’re overstating the external impact. This would have been bad PR a decade ago, but today PHP language evolution is not front of mind for many outside the PHP community.
I believe (from discussions in the list and online) that most of the people who voted it down have done so due to a very clear philosophical objection to partially-erased types. Those people do not want the biggest potential follow-on from this RFC, which is language support for erased generic
array<string>, a construct which has existed in docblocks for a couple of decades.I think it’s useful to have these decisions written in stone.
I don’t believe there’s a better proposal for erased generics than this one. In the future, when someone asks why PHP doesn’t have erased generics, we can point to this vote.
I agree 100%, voters should take responsibility for their own actions, instead of asking to hold off the vote indefinitely, constantly requesting changes.
If this RFC is rejected, PHP won’t have generics (at least not in 2026/the first half of 2027 due to the cooling off period of RFCs of the same type).
Kind regards,
Daniil Gentili.
I agree 100%, voters should take responsibility for their own actions, instead of asking to hold off the vote indefinitely, constantly requesting changes.
I think it's generally preferable for the main aim to be reaching consensus, and a vote confirming that consensus, rather than treating votes as something to be "won" and "lost".
However, if there's genuine deadlock in a discussion, I guess bringing to a vote is a way to get a decision made.
If this RFC is rejected, PHP won’t have generics (at least not in 2026/the first half of 2027 due to the cooling off period of RFCs of the same type).
That is, luckily, not what the policy says; it says "it will not be allowed to bring up a rejected proposal for another vote, unless ... the authors make substantial changes to the proposal". So an RFC building on Seifeddine's work but taking a different approach to enforcement could be brought forward at any time.
Holding a vote is not, and should not be, a way to block alternatives or counter-proposals.
Let's not get into the rhetoric of "this is your only chance for generics". If the vote is going ahead, people should vote on this specific proposal, with the specific tradeoffs it includes.
It's great that we're making progress towards generics; now let's work together to get the best version of them we can.
Rowan Tommins
[IMSoP]
Le 15/06/2026 à 10:51, Rowan Tommins [IMSoP] a écrit :
I agree 100%, voters should take responsibility for their own actions, instead of asking to hold off the vote indefinitely, constantly requesting changes.
I think it's generally preferable for the main aim to be reaching consensus, and a vote confirming that consensus, rather than treating votes as something to be "won" and "lost".However, if there's genuine deadlock in a discussion, I guess bringing to a vote is a way to get a decision made.
The discussion thread on the internals list is already huge, so I guess
at least a substantial proportion of the people who voted have already
expressed themselves.
And to what I've read on the thread, the decision were made on this
RFC, not on the concept of Generics itself.
If this RFC is rejected, PHP won’t have generics (at least not in 2026/the first half of 2027 due to the cooling off period of RFCs of the same type).
That is, luckily, not what the policy says; it says "it will not be allowed to bring up a rejected proposal for another vote, unless ... the authors make substantial changes to the proposal". So an RFC building on Seifeddine's work but taking a different approach to enforcement could be brought forward at any time.
Holding a vote is not, and should not be, a way to block alternatives or counter-proposals.
Let's not get into the rhetoric of "this is your only chance for generics". If the vote is going ahead, people should vote on this specific proposal, with the specific tradeoffs it includes.
It's great that we're making progress towards generics; now let's work together to get the best version of them we can.
One of my interpretations is that "complete generics" isn't possible
per-se considering the current way the compiler and engine work.
However, it's not impossible to implement "generic-like systems", and
maybe a smaller RFC, for example about typed
arrays/ArrayObject/Iterator, could already bring a lot of value, without
having full generics yet.
And to what I've read on the thread, the decision were made on this RFC, not on the concept of Generics itself.
I was responding directly to Daniil's comment starting "if this RFC is rejected...", not commenting on how anyone has voted.
If this RFC is rejected, it means only that this specific proposal is rejected, and there are plenty of options being discussed for alternatives.
I did not want a statement implying differently to stand unchallenged.
Rowan Tommins
[IMSoP]