# [RFC] Primary Constructors

- Thread: https://externals.io/message/131565
- Original archive: https://news-web.php.net/php.internals/131565
- Started by Rob Landers on 2026-06-29T00:17:46+00:00
- Messages: 44
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/131565.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #131565 — Rob Landers — 2026-06-29T00:17:46+00:00

URL: https://externals.io/message/131565#131565

Hello internals,

I'd like to put forward Primary Constructors <https://wiki.php.net/rfc/primary-constructors> for comment.

An implementation PR will be opened later today (UTC), and the RFC updated with this discussion thread.

— Rob

---

## #131566 — Nick Sdot — 2026-06-29T06:31:28+00:00

URL: https://externals.io/message/131565#131566 · In reply to: #131565

> Hello internals,
>
> I'd like to put forward Primary Constructors 
> <https://wiki.php.net/rfc/primary-constructors> for comment.
>
> An implementation PR will be opened later today (UTC), and the RFC 
> updated with this discussion thread.
>
> — Rob


Hey Rob,

thanks again for the work you did put into this!

Unfortunately you are not allowing bodies for primary constructor. This 
means there will be no way to work around the "`readonly` classes don't 
allow property hooks" problematic; except using conventional 
constructors (`private(set)` is not the same; hence my previous 
"readonly hooks" RFC).

If "use conventional constructors, if you need `readonly` classes" 
stands, then the same can be argued for everything else in the RFC.

Why would we introduce a whole new syntax, but then only make it work 
for limited use-cases such as "trivial validation or normalization"?

Your example:

```

class Money(
     public readonly int$amount,
     public readonly string$currency = 'USD',
) {}

class Money{
     public function __construct(
         public readonly int$amount,
         public readonly string$currency = 'USD',
     ) {}
}

```

Pro:
- two lines less
- construction at top of class (love it!)

Con:
- primary constructor body not supported
- new syntax with gotchas to keep in mind
- for readonly classes it adds two property `readonly` in exchange to 
writing two lines less
- requires refactoring to conventional constructor as soon as it gets 
"non-trivial" (I'd argue a lot of things that do not work are actually 
still trivial).

Given the limitations, is this alone adding enough value? What is the 
actual gain?

Adding a new syntax to the language but then lock it down as proposed 
here does not feel right.
As is, I feel the proposal is too thin, it would unfortunately be yet 
another feature that feels mid, incomplete, and introduces new gotchas.
Sorry, IMO, not worth it.

If we would say we want new and neat syntax sugar to write constructors 
at the top of the class, I am all for it!
But then they would need to work like actual constructors (otherwise 
it's not just sugar), without accepting yet another set of limitations 
and weirdness's in a different place.

What I roughly have in mind:

```
readonly class Point(public int $x, int $id = 0) extends Base($id) 
implements Foo {
    // normal constructor body behaviour
} => {
   // class body
}
```

--

Cheers
Nick

---

## #131567 — Rowan Tommins [IMSoP] — 2026-06-29T08:00:36+00:00

URL: https://externals.io/message/131565#131567 · In reply to: #131566

>
> 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.

In fact, I don't think even property hooks belong in a primary 
constructor; they're ugly enough in a constructor promoted property.

I think it's perfectly fine to have short-hands that only cover specific 
use cases, and longer forms that let you express more complex use 
cases. It's one of the reasons I voted against the recent RFC to allow 
an extra reassignment of properties in the constructor 
[https://wiki.php.net/rfc/promoted_readonly_constructor_reassign].


-- 
Rowan Tommins
[IMSoP]

---

## #131568 — Nick Sdot — 2026-06-29T08:47:41+00:00

URL: https://externals.io/message/131565#131568 · In reply to: #131567

Hey Rowan,


> 
> > […]
>
> 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?

> In fact, I don't think even property hooks belong in a primary 
> constructor; they're ugly enough in a constructor promoted property.

It's a feature that was accepted to PHP and exists already. So it 
doesn't really matter whether we (I agree -- shouldn't be used for 
anything more than eg a neat callback) find it ugly and we have to deal 
with its existence. You are basically making a point for allowing 
primary constructor bodies. Having them allows to have a readonly 
classes with primary constructors, and assign properties in their body. 
Neat.

> I think it's perfectly fine to have short-hands that only cover 
> specific use cases, and longer forms that let you express more complex 
> use cases. It's one of the reasons I voted against the recent RFC to 
> allow an extra reassignment of properties in the constructor 
> [https://wiki.php.net/rfc/promoted_readonly_constructor_reassign]. 


For the record, my view is completely the opposite: without allowing 
primary constructor bodies the added value of adding the new syntax is 
nearly non-existent.

Quoting from your message in the first thread to this:

> I don't think we should add extra syntax to the language just to 
> change people's habits. If you want a constructor body as the first 
> thing in the class, you can do that right now.


...because the exact argument can be made from either point of view. To 
quote you again: "all or nothing"; bodies should be allowed.

--

Cheers
Nick

---

## #131572 — Lynn — 2026-06-29T10:27:23+00:00

URL: https://externals.io/message/131565#131572 · In reply to: #131565

> Hello internals,
>
> I'd like to put forward Primary Constructors
> <https://wiki.php.net/rfc/primary-constructors> for comment.
>
> An implementation PR will be opened later today (UTC), and the RFC updated
> with this discussion thread.
>
> — Rob
>

I don't see any mention of anonymous classes, I assume they aren't
compatible syntax wise?

---

## #131574 — Rob Landers — 2026-06-29T10:52:45+00:00

URL: https://externals.io/message/131565#131574 · In reply to: #131572

> 
> 
> 
> > […]
> 
> I don't see any mention of anonymous classes, I assume they aren't compatible syntax wise? 

Hi Lynn,

That's a good observation! Originally, I had a whole section and decided to strip it, then forgot to add it back as non-supported and future scope. FWIW, I was originally going to support them with something like:

$arg = 'foo';
$class = new class(public int $x = $arg) {}

Which desugars to:

$arg = 'foo';
$class = new class($arg) {
  public function __construct(public int $x) {}
}

There are a lot of caveats, which is why I dropped it for future scope:
 1. it would require types on the input parameters to disambiguate between arguments and properties
 2. it gets weird if you don't specify a default value for the property and makes it ambiguous as a constructor
 3. which begs the question of always having a default
In essence, it deserves its own RFC because there is a lot of subtlety and only makes sense in the context that primary constructors exist in the first place.

I'll address it in the RFC, thanks!

— Rob

---

## #131577 — Rob Landers — 2026-06-29T11:03:57+00:00

URL: https://externals.io/message/131565#131577 · In reply to: #131568

Hi, Nick,


> Hey Rowan,
> 
> 
> > […]
> 
> 
> 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. This syntax doesn't prevent you from using readonly classes. It only prevents you from initialization/validation in a body because there are no bodies. If you need a body, use a constructor -- that's what they're for. The RFC makes it plain that bodies are rejected and why. 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.

— Rob

---

## #131578 — Rob Landers — 2026-06-29T11:19:06+00:00

URL: https://externals.io/message/131565#131578 · In reply to: #131565

> Hello internals,
> 
> I'd like to put forward Primary Constructors <https://wiki.php.net/rfc/primary-constructors> for comment.
> 
> An implementation PR will be opened later today (UTC), and the RFC updated with this discussion thread.
> 
> — Rob

I've updated the RFC with an implementation URL, the link to the mailing list thread, and information regarding anonymous classes.

— Rob

---

## #131579 — Lynn — 2026-06-29T11:30:00+00:00

URL: https://externals.io/message/131565#131579 · In reply to: #131574

>
>
> 
>
>
>
> 
>
>
> Hello internals,
>
> I'd like to put forward Primary Constructors
> <https://wiki.php.net/rfc/primary-constructors> for comment.
>
> An implementation PR will be opened later today (UTC), and the RFC updated
> with this discussion thread.
>
> — Rob
>
>
> I don't see any mention of anonymous classes, I assume they aren't
> compatible syntax wise?
>
>
> Hi Lynn,
>
> That's a good observation! Originally, I had a whole section and decided
> to strip it, then forgot to add it back as non-supported and future scope.
> FWIW, I was originally going to support them with something like:
>
> $arg = 'foo';
> $class = new class(public int $x = $arg) {}
>
>
> Which desugars to:
>
> $arg = 'foo';
> $class = new class($arg) {
>   public function __construct(public int $x) {}
> }
>
>
> There are a lot of caveats, which is why I dropped it for future scope:
>
>    1. it would require types on the input parameters to disambiguate
>    between arguments and properties
>    2. it gets weird if you don't specify a default value for the property
>    and makes it ambiguous as a constructor
>    3. which begs the question of always having a default
>
> In essence, it deserves its own RFC because there is a lot of subtlety and
> only makes sense in the context that primary constructors exist in the
> first place.
>
> I'll address it in the RFC, thanks!
>
> — Rob
>

I think the only thing that needs to be solved for anonymous classes would
be the syntax. Seeing there's always a visibility/type in property
promotion, I think it should be clear it's going to be style (A) or (B)
based on the syntax as you can't mix. I can't see a scenario where you
would write:

$class = new class(public int $x) {}

Where as the following would be just fine:

$class = new class(public int $x = 0) {};          // construct with
property $x being 0
$class = new class(public int|null $x = null) {};  // construct with
property $x being null
$class = new class(public int $x = $x) {};         // construct with
$x from local scope into property $x
$class = new class(public int $x = $this->x) {};   // construct with
$this->x from the instance scope
$class = new class(public int $x = self::$x) {};   // construct with
$this->x from the static self scope

Bonus points if the body becomes optional:

$class = new class(public int $x = 0, public int $y = 0);

This would be the existing style and remains unchanged

$class = new class($localScope) {};

Mixing would error as you can't pick both:

$class = new class(public int $x = 0, $y) {}; // Nothing handles $y as
no body is allowed
$class = new class($x, public int $y = 0) {}; // Can't allow the
latter as $x requires a body to do something


Perhaps this isn't as simple as I think it is, but this would be a nice +
to have in this RFC. I think it's fine to keep the initial implementation
rather restrictive, it can always be improved upon in the future.

---

## #131581 — Nick Sdot — 2026-06-29T11:42:31+00:00

URL: https://externals.io/message/131565#131581 · In reply to: #131577

Hey Rob,


> Hi, Nick,
>
> 
> > […]
>
> 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.
> It only prevents you from initialization/validation in a body because 
> there are no bodies. 


Right. Which makes them useless in endless situations.

> 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?
> 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?
> 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.

> — Rob

--

Cheers
Nick

---

## #131583 — Rowan Tommins [IMSoP] — 2026-06-29T12:07:32+00:00

URL: https://externals.io/message/131565#131583 · In reply to: #131574

>
> FWIW, I was originally going to support them with something like:
>
>$arg = 'foo';
>$class = new class(public int $x = $arg) {}
>
>Which desugars to:
>
>$arg = 'foo';
>$class = new class($arg) {
>  public function __construct(public int $x) {}
>}


I actually have a draft RFC kicking around for this, but using a different syntax inspired by closures:

$arg = 'foo';
$class = new class() use (public int $arg) {}

This allows a very concise version for very simple cases: 

$class = new class() use ($arg) {}


I even had a working implementation, but paused it to work out if a constructor could be allowed as well. If the syntax allowed for a parent constructor call, though, that might be enough for most use cases.

Although it's not obvious, anonymous classes are actually compiled once, and then constructed multiple times, which means the syntax is doing quite a lot more than constructor promotion.

I agree that it should be left as future scope to pin down exactly how it should look and work.


Rowan Tommins
[IMSoP]

---

## #131585 — Rob Landers — 2026-06-29T13:35:01+00:00

URL: https://externals.io/message/131565#131585 · In reply to: #131581

> Hey Rob,
> 
> 
> > […]
> 
> 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.

> > […]
> 
> 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.

> > […]
> 
> 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.

> > […]
> 
> 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.

> > […]
> 
> 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.

> 
> > […]
> --
> 
> Cheers
> Nick
> 

— Rob

---

## #131591 — Larry Garfield — 2026-06-29T16:40:29+00:00

URL: https://externals.io/message/131565#131591 · In reply to: #131574

> 
> > […]
>
> Hi Lynn,
>
> That's a good observation! Originally, I had a whole section and 
> decided to strip it, then forgot to add it back as non-supported and 
> future scope. FWIW, I was originally going to support them with 
> something like:
>
> $arg = 'foo';
> $class = new class(public int $x = $arg) {}
>
> Which desugars to:
>
> $arg = 'foo';
> $class = new class($arg) {
>   public function __construct(public int $x) {}
> }
>
> There are a lot of caveats, which is why I dropped it for future scope:
>  1. it would require types on the input parameters to disambiguate 
> between arguments and properties
>  2. it gets weird if you don't specify a default value for the property 
> and makes it ambiguous as a constructor
>  3. which begs the question of always having a default
> In essence, it deserves its own RFC because there is a lot of subtlety 
> and only makes sense in the context that primary constructors exist in 
> the first place.
>
> I'll address it in the RFC, thanks!
>
> — Rob

For anon classes, I would think the best approach is to have a compact, non-redundant syntax for "take this value from current scope and assign it to a property in this class."  Basically combining promotion and closure.  Doing that right now is horribly ugly.

That may well be out of scope for this RFC, and that's fine, but I wanted to put that out there.

--Larry Garfield

---

## #131592 — Larry Garfield — 2026-06-29T16:59:14+00:00

URL: https://externals.io/message/131565#131592 · In reply to: #131565

> Hello internals,
>
> I'd like to put forward Primary Constructors 
> <https://wiki.php.net/rfc/primary-constructors> for comment.
>
> An implementation PR will be opened later today (UTC), and the RFC 
> updated with this discussion thread.
>
> — Rob

I support this feature, and am glad to see it.  It will make struct-objects that much easier to write, as well as more interesting value objects.

To the objections about readonly... Seriously, readonly is broken. :-)  Use private(set) instead and you get essentially the same effect, unless you're doing something screwy inside your class.  And if you are, then you already know it.

As Rob already noted, there's a massive number of existing classes where it's not even an issue: There's no hooks or need for them, and readonly works fine then.  Or switching them over to private(set) if adding a hook in the future is not hard.  (Unless there's inheritance involved, and then the problem is inheritance. :-) )

We can't remove readonly from the language, but we should not allow its limitations and flaws to keep us from making our lives easier.

The RFC has no mention of attributes.  An example of that would be helpful, even though I presume it's exactly what one would expect it to be.

The one addition I would ask for is to note that in Kotlin and Swift, there is a post-primary-constructor initializer, called an `init` block.  It has no body, but lets you do post-property-assignment stuff.  It's basically an argument-free constructor.  I think that would go a long way toward smoothing the concerns people have about this feature being too "locked down."

If we don't want a new keyword for it, we could allow a __construct method that has NO arguments if there is a primary constructor.  It would get called last, after everything else (including parent constructors if appropriate) has run.  (Whether it's spelled `__construct() { ]]` or `__construct {  }`, I don't have a strong opinion.)  A __construct that does take arguments would still be a compile-time conflict with a primary constructor.

--Larry Garfield

---

## #131594 — Rowan Tommins [IMSoP] — 2026-06-29T17:11:49+00:00

URL: https://externals.io/message/131565#131594 · In reply to: #131591

>For anon classes, I would think the best approach is to have a compact, non-redundant syntax for "take this value from current scope and assign it to a property in this class."  Basically combining promotion and closure.  Doing that right now is horribly ugly.

Yeah, that was precisely my starting point. The "use" syntax I came up with felt pretty clear and flexible, but some off-list review suggested that fabricating a constructor behind the scenes was not ideal, because there are use cases for combining it with a real constructor.

I was looking into alternative ways to inject the values into the instance, such as an extra opcode like the one closures use; but Real Life intervened and I haven't got back to it for a while.

I would need to look back at notes and discussions to see if there were use cases mentioned other than parent constructor calls. Maybe the "parameter forwarding" syntax from this RFC could be combined with what I had somehow.



Rowan Tommins
[IMSoP]

---

## #131605 — Eric Norris — 2026-06-29T18:44:37+00:00

URL: https://externals.io/message/131565#131605 · In reply to: #131592

>
> 
> > […]
>
> I support this feature, and am glad to see it.  It will make struct-objects that much easier to write, as well as more interesting value objects.
>
> To the objections about readonly... Seriously, readonly is broken. :-)  Use private(set) instead and you get essentially the same effect, unless you're doing something screwy inside your class.  And if you are, then you already know it.
>
> As Rob already noted, there's a massive number of existing classes where it's not even an issue: There's no hooks or need for them, and readonly works fine then.  Or switching them over to private(set) if adding a hook in the future is not hard.  (Unless there's inheritance involved, and then the problem is inheritance. :-) )
>
> We can't remove readonly from the language, but we should not allow its limitations and flaws to keep us from making our lives easier.

I'm afraid of going off-topic, but I disagree that "readonly is
broken." In what way is it broken? A large part of the disagreement in
the previous "readonly hooks" RFC was over the *meaning* of readonly.
I'd have to fully go back to remind myself of the nuance, but my
recollection is that it works exactly how I (and others, per the vote
outcome) expect.

I recall that it seemed like what people wanted was to have something
only *publicly* readable, but internally writable, which is in fact
what you're suggesting as an alternative - asymmetric visibility
(private(set)) - and is not what readonly is for, even if the name
lends itself to confusion. I think you had even described it as
"write-once", at one point, which more closely matches my expectation
and desire of the keyword.

I recall that I (and someone else?) had thrown out a suggestion for
"init" hooks, that I think would have addressed what some people were
looking for (having a hook with a readonly property for
initialization), but not others (get hooks for readonly, since that
breaks the "main" interpretation of the readonly RFC). Again, this was
a while ago so I'm a little fuzzy, but I would absolutely consider
voting yes for an "init" hook RFC; I could arguably see that as
compatible with the readonly keyword, and thus, readonly would be
compatible with (a subset of) hooks.

This is not meant to be a combative email by the way, I just want to
make sure it's clear that I believe readonly is not something that we
should remove or consider baggage.

---

## #131606 — Seifeddine Gmati — 2026-06-29T18:54:47+00:00

URL: https://externals.io/message/131565#131606 · In reply to: #131565

>
> Hello internals,
>
> I'd like to put forward Primary Constructors for comment.
>
> An implementation PR will be opened later today (UTC), and the RFC updated with this discussion thread.
>
> — Rob

Hi Rob,

Personally, I really dislike this feature.

It adds a new syntax that increases the complexity of the PHP grammar,
which is already quite complex, for no real advantage. It's just a
slightly different way to write something the language already
expresses.

It's also confusing to read. A line like:

```
class Foo(public int $a, public string $b) extends Base($a, $b) { ... }
```

jumps from class definition, to constructor definition, to class
definition again (inheritance), to what is effectively a
`parent::__construct()` call, and then back into the class body.
That's a lot of distinct concepts packed into a single line, with no
syntactic separation to signal the shift from one to the next.

Cheers,
Seifeddine.

---

## #131607 — tim@bastelstu.be — 2026-06-29T19:04:05+00:00

URL: https://externals.io/message/131565#131607 · In reply to: #131605

Hi

Am 2026-06-29 20:44, schrieb Eric Norris:
> I'm afraid of going off-topic, but I disagree that "readonly is
> broken." In what way is it broken? A large part of the disagreement in
> the previous "readonly hooks" RFC was over the *meaning* of readonly.
> I'd have to fully go back to remind myself of the nuance, but my
> recollection is that it works exactly how I (and others, per the vote
> outcome) expect.
> 
> […]
> 
> This is not meant to be a combative email by the way, I just want to
> make sure it's clear that I believe readonly is not something that we
> should remove or consider baggage.

I'm in full agreement on the quoted sections.

Best regards
Tim Düsterhus

---

## #131608 — tim@bastelstu.be — 2026-06-29T19:07:34+00:00

URL: https://externals.io/message/131565#131608 · In reply to: #131565

Hi

Am 2026-06-29 02:17, schrieb Rob Landers:
> I'd like to put forward Primary Constructors 
> <https://wiki.php.net/rfc/primary-constructors> for comment.

The RFC currently does not specify the interaction with visibility. It 
is currently implied that the constructor will be `public`, but the RFC 
doesn't spell that out and doesn't specify whether or not it is possible 
to make such a constructor non-public (e.g. to actually treat it as a 
“primary constructor” in a sea of multiple named constructors).

Best regards
Tim Düsterhus

---

## #131609 — Rob Landers — 2026-06-29T19:08:41+00:00

URL: https://externals.io/message/131565#131609 · In reply to: #131606

> 
> > […]
> 
> Hi Rob,
> 
> Personally, I really dislike this feature.

Sincerely, thank you for your opinion.

> 
> It adds a new syntax that increases the complexity of the PHP grammar,
> which is already quite complex, for no real advantage. It's just a
> slightly different way to write something the language already
> expresses.
> 
> It's also confusing to read. A line like:
> 
> ```
> class Foo(public int $a, public string $b) extends Base($a, $b) { ... }
> ```
> 
> jumps from class definition, to constructor definition, to class
> definition again (inheritance), to what is effectively a
> `parent::__construct()` call, and then back into the class body.
> That's a lot of distinct concepts packed into a single line, with no
> syntactic separation to signal the shift from one to the next.
> 
> Cheers,
> Seifeddine.

It's also the entire point of the feature ;) You open the file, and in two seconds, you know:

It defines two properties, type int and string, it calls parent::__construct with those two parameters.

Currently, you open the class, seek to the constructor, read it to understand if it even calls the parent constructor or not. Just like promoted properties, the cost is nominal, but now it is nearly ubiquitous in usage and saves a large amount of time in reading and writing classes. This feature seeks to do the same.

— Rob

---

## #131610 — tim@bastelstu.be — 2026-06-29T19:10:33+00:00

URL: https://externals.io/message/131565#131610 · In reply to: #131592

Hi

Am 2026-06-29 18:59, schrieb Larry Garfield:
> The RFC has no mention of attributes.  An example of that would be 
> helpful, even though I presume it's exactly what one would expect it to 
> be.

I second that the RFC needs to specify this, *because* I don't consider 
this obvious at all and I'm positive that the expectations from users 
differ wildly. What do your expectations look like?

Best regards
Tim Düsterhus

---

## #131611 — Nick Sdot — 2026-06-29T19:20:06+00:00

URL: https://externals.io/message/131565#131611 · In reply to: #131585

Hey Rob,


> 
> > […]
>
> 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...
>
> > […]
>
> 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.
> > […]
>
> 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.
> > […]
>
> Will do.
> > […]
>
> 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

---

## #131612 — Seifeddine Gmati — 2026-06-29T19:21:22+00:00

URL: https://externals.io/message/131565#131612 · In reply to: #131609

> It's also the entire point of the feature ;) You open the file, and in two seconds, you know:
>
> It defines two properties, type int and string, it calls parent::__construct with those two parameters.
>
> Currently, you open the class, seek to the constructor, read it to understand if it even calls the parent constructor or not. Just like promoted properties, the cost is nominal, but now it is nearly ubiquitous in usage and saves a large amount of time in reading and writing classes. This feature seeks to do the same.

> It's also the entire point of the feature ;) You open the file, and in
> two seconds, you know:
>
> It defines two properties, type int and string, it calls
> parent::__construct with those two parameters.
>
> Currently, you open the class, seek to the constructor, read it to
> understand if it even calls the parent constructor or not. Just like
> promoted properties, the cost is nominal, but now it is nearly
> ubiquitous in usage and saves a large amount of time in reading and
> writing classes. This feature seeks to do the same.

I don't think the "seek to the constructor" problem is real in practice.
By convention the constructor goes first in a PHP class, so the code
you'd be reading is simply:

```
class Foo extends Base
{
  public function __construct(public int $a, public string $b)
  {
    parent::__construct($a, $b);
  }
}
```

That's seven lines that fit comfortably on any screen, and each concept,
the class, the constructor, the promoted properties, the parent call,
sits on its own line where it's immediately recognizable. Packing all of
it onto a single line saves nothing and makes the code harder to read,
not easier.

I also disagree with comparing this to promoted properties. Promoted
properties removed genuine boilerplate: the property declaration, the
constructor parameter, and the `$this->x = $x` assignment collapsed into
one place because they were the same information repeated three times.
Primary constructors don't remove repetition; they just relocate the
constructor signature into the class declaration line. There's no
duplicated information being eliminated.

Cheers,
Seifeddine.

---

## #131613 — Nick Sdot — 2026-06-29T19:29:16+00:00

URL: https://externals.io/message/131565#131613 · In reply to: #131592

Hey Larry,


> 
> > […]
> I support this feature, and am glad to see it.  It will make struct-objects that much easier to write, as well as more interesting value objects.
>
> To the objections about readonly... Seriously, readonly is broken. :-)  Use private(set) instead and you get essentially the same effect, unless you're doing something screwy inside your class.  And if you are, then you already know it.

I know you will not get tired trying to sell us private(set) -- but it's 
not the same; one prevents a programmer error, the other not. We cannot 
one time argue we need guardrails and don't hand out foot guns, and when 
it doesn't suit the argument we ignore it.

> As Rob already noted, there's a massive number of existing classes where it's not even an issue: There's no hooks or need for them, and readonly works fine then.  Or switching them over to private(set) if adding a hook in the future is not hard.  (Unless there's inheritance involved, and then the problem is inheritance. :-) )
>
> We can't remove readonly from the language, but we should not allow its limitations and flaws to keep us from making our lives easier.
Bud, you make it sound as if there would be no other solution. Simply 
allowing a body for primary constructors *is* the solution. And it 
doesn't require readonly to be removed from the language. ;)
> The RFC has no mention of attributes.  An example of that would be helpful, even though I presume it's exactly what one would expect it to be.
>
> The one addition I would ask for is to note that in Kotlin and Swift, there is a post-primary-constructor initializer, called an `init` block.  It has no body, but lets you do post-property-assignment stuff.  It's basically an argument-free constructor.  I think that would go a long way toward smoothing the concerns people have about this feature being too "locked down."
>
> If we don't want a new keyword for it, we could allow a __construct method that has NO arguments if there is a primary constructor.  It would get called last, after everything else (including parent constructors if appropriate) has run.  (Whether it's spelled `__construct() { ]]` or `__construct {  }`, I don't have a strong opinion.)  A __construct that does take arguments would still be a compile-time conflict with a primary constructor.
>
> --Larry Garfield
--

Cheers
Nick

---

## #131614 — tim@bastelstu.be — 2026-06-29T19:37:47+00:00

URL: https://externals.io/message/131565#131614 · In reply to: #131611

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

---

Next page: https://externals.io/message/131565.md?page=2