Hi
Am 2026-06-29 21:20, schrieb Nick Sdot:
Well, this is going to be more of a general thing, nothing exclusive to
your RFC... But this is how we end up with more and more half finished
and awkward (to not say broken) features in PHP. While I understand and
generally support "get the minimum in and iterate later" from the
perspective of RFC authors, reality shows that "later" can be either
years later or very likely never at all. Though, we will have to deal
with the unfinished/broken "minimum" solutions. How many more of these
do we want to add?
To name three from the top of my mind:
1/ we still don't have stringable enums
2/ we still don't have a solution for widening the type of a promoted
property's set hooks (hi #16638), and of course
3/ my beloved readonly hooks themselves. ;)
I consider (1) and (3) to be fundamentally wrong from a semantic
perspective, i.e. a “Won’t fix”, not a missing feature.
For (2) I agree that the situation is unfortunate, but as you say:
[…] See my comment to #16638; we probably should just have skipped
hooks on promoted properties unless there would have been a solution
before release.
… here the correct fix would've been making the feature *smaller* rather
than *larger*, which is the opposite of what you are proposing here.
And for this RFC I agree with Rob that not allowing an explicit body
with “primary constructors” is the correct choice to prevent confusion:
The limitations are a feature that makes classes using “Primary
Constructors” easy to reason about. “Reduce typing” alone is not a
sufficiently strong argument in favor of a new feature. As an example,
promoted properties are not just “fewer characters to type”, but have
the added benefit of “keeping data types in sync between parameter and
property”, thus reducing mistakes. I don't see such a benefit for
primary constructors if they are capable of doing everything a regular
constructor can.
Best regards
Tim Düsterhus
