Hey Rob,
On 29.06.26 21:35, Rob Landers wrote:
On Mon, Jun 29, 2026, at 13:42, Nick Sdot wrote:
Hey Rob,
On 29.06.26 19:03, Rob Landers wrote:
Hi, Nick,
On Mon, Jun 29, 2026, at 10:47, Nick Sdot wrote:
Hey Rowan,
On 29.06.26 16:00, Rowan Tommins [IMSoP] wrote:
> On 29/06/2026 07:31, Nick Sdot wrote:
>>
>> If "use conventional constructors, if you need `readonly` classes"
>> stands, then the same can be argued for everything else in the RFC.
>>
>
> For the record, my view is completely the opposite: if the new
syntax
> allows everything a normal constructor does, just in a slightly
> different position, it will lead to endless style discussions of
which
> to use.
That's a fair opinion, and not unexpected. Personally, I oppose
introducing more inconsistencies to PHP. Looks like that we need to
have
these discussions then?
There's no inconsistency here.
The inconsistency is that we will have two kind of constructors. One
that has a body, one has not. It's a completely new concept, but you
talk about syntax sugar.
There's only one constructor; PHP doesn't allow you to have different
constructors. You choose the spelling that makes the most sense for
your class and objectives. This is just declaration, not logic.
Dude...
It only prevents you from initialization/validation in a body
because there are no bodies.
Right. Which makes them useless in endless situations.
Of all the PHP code on my machine (production application code,
frameworks like symfony/laravel/doctrine) ... it's about 30-40% of all
constructors that are completely empty. I also sent an LLM to look
further at things that could benefit from this (ie, promote properties
on older code instead of just empty constructors). It came back with
71% of Laravel and 61% of Symfony that could use Primary Constructors.
I'm not saying they should go rewrite their code or anything like
that, but that basically means at least 1-2 out of 3 classes written
in a given codebase could use primary constructors to simplify their
construction and make it easier to skim.
My 2¢: I don't think this is useless.
I did not say it is useless, I did say it is useless in endless
situations. And it is avoidable, by allowing a body.
If you need a body, use a constructor -- that's what they're for.
But then I cannot benefit from the position (at the top of the class)
of the primary constructors, which I really would like. Shouldn't we
try to make each new feature as useful as possible? What are the
actual blockers to not support primary constructor bodies?
There is nothing preventing a follow-up RFC from being proposed, but
as well as anonymous classes, it deserves its own RFC. There's a lot
of syntax to bike-shed, as well as questions like "if I give a body,
can I still use a parent constructor shortcut?" It is not
straightforward and nor should it be. I fully explored this in the
Records RFC, and many people pushed back on the logic, even pointed
out unsoundness in what seemed like an otherwise sound design.
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. ;)
You know, I don't argue for the sake of it. It's just too often that my
concerns turn out to be valid, eventually. See my comment to #16638; we
probably should just have skipped hooks on promoted properties unless
there would have been a solution before release. Now we have to deal
with this inconsistent and broken behaviour for forever (?), because
people are already busy with the next features. If we already not get
such features right (no blame to anyone -- it's complex!), imagine what
a disaster introducing native inline generics (with all its "good follow
up RFC") could have lead to, if they would have made it in the language
before PHP even has the will to agree on an internals approved official
PHPDoc types spec that can prove itself over a few years without
breaking code.
Point is, I care. That's why I voice my concerns.
"if I give a body, can I still use a parent constructor shortcut?"
My opinion: usage of parent constructor shortcut forbids manual parent
constructor calling, and vice versa. Makes sense to me, and sounds easy
to reason about.
Other people could see that different, yes. But that's why I think it
should be discussed *now*, instead of postponing to likely never, and
then again have a "half nice" feature to deal with. Will the discussions
be more complex? Yes. Will they take much longer? Yes. Could it lead to
that the feature doesn't get in at all, not even in the minimum version?
Yes. But I am honestly at a point where I think that's a good thing.
Better nothing than yet another "mid" one that is annoying.
The RFC makes it plain that bodies are rejected and why.
It's possible that I missed where the "why" was explained, but I
don't see explanations apart from "expressed in property hooks";
which I am here pointing out will not work in readonly classes. Could
you please make the "why" more clear in the RFC?
Will do.
If you can provide a concrete reason why they should be allowed with
a completely new syntax, that would be a good follow-up RFC; or even
a competing one. If you disagree with the reasoning, I'd love to
hear it.
The concrete reason is what I already mentioned: it will not work
with readonly classes and `private(set)` is not the same.
It's not that readonly for value projects is a rare thing.
Where do you see in the RFC that it won't work with readonly classes,
because that would be an error on my part? It explicitly does not
prevent you from using any type of class except enums. If you're
referring to the usage of primary constructors in combination with
hooks and readonly, that's an orthogonal issue that belongs to the
interaction between hooks and readonly and is far out of scope from
this RFC. That is a limitation that exists today and this RFC does not
strive to address it.
Respectfully, your answer is misleading. The limitation exist, yes. But
with your proposal you introduce a new layer to the problem that your
proposal of course should strive to address. Conventional constructors
do have a body that allow working around the limitation. You intend to
add new syntax that deliberately prevents a workaround by not allowing a
body. So, please, "not my beer" is a little too blunt here. How the
feature is proposed makes it less adaptable, and again introduces new
gotchas. Bad for us, bad for the language.
Should harder discussions, caused by body behaviour, really be a reason
to add another "well, just good enough" in?
--
Cheers
Nick
