On 30.06.26 03:47, Rob Landers wrote:
On Mon, Jun 29, 2026, at 21:20, Nick Sdot wrote:
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.
The irony here is that this is a follow-up RFC born weeks after
someone reminded me about this part of it. It was abandoned due to
comments like this.
I do think I have a track record of attempting interesting RFCs and
then abandoning them because it's clear nobody wants them. And that's
fine. As I've stated multiple times in this thread, it would explode
the complexity of the RFC. Probably half of it would just be about
constructors. That's clear it should be a separate RFC, and if I did
present it, you (or someone else) would argue that it needs to be
broken up -- just like the records RFC.
I show up, because I care as well; but damn, everyone can't always
have cake.
— Rob
I loved the Records RFC -- see my comments on Twitter about it -- and I
would not have asked you to break it up. But I would have asked why we
need both inline and conventional constructors in the same time, instead
of just the genius inline (now primary) constructors with a body. ;)
My intention is not to demotivate you, fwiw. Keen to talk about the
complexity.
--
Cheers
Nick
