[PHP-DEV] [RFC] Primary Constructors

Rob_Landers1 · June 29, 2026, 12:17am

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

Nick · June 29, 2026, 6:31am

On 29.06.26 08:17, Rob Landers wrote:

Hello internals,

I'd like to put forward Primary Constructors <PHP: 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

Rowan_Tommins_IMSoP · June 29, 2026, 8:00am

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.

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 [PHP: rfc:promoted_readonly_constructor_reassign].

--
Rowan Tommins
[IMSoP]

Nick · June 29, 2026, 8:47am

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?

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 [PHP: 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

Lynn · June 29, 2026, 10:27am

On Mon, Jun 29, 2026 at 2:20 AM Rob Landers <rob@getswytch.com> wrote:

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

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

Rob_Landers1 · June 29, 2026, 10:52am

On Mon, Jun 29, 2026, at 12:27, Lynn wrote:

On Mon, Jun 29, 2026 at 2:20 AM Rob Landers <rob@getswytch.com> wrote:

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

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:

it would require types on the input parameters to disambiguate between arguments and properties
it gets weird if you don’t specify a default value for the property and makes it ambiguous as a constructor
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

Rob_Landers1 · June 29, 2026, 11:03am

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

Rob_Landers1 · June 29, 2026, 11:19am

On Mon, Jun 29, 2026, at 02:17, Rob Landers wrote:

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

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

— Rob

Lynn · June 29, 2026, 11:30am

On Mon, Jun 29, 2026 at 12:56 PM Rob Landers <rob@getswytch.com> wrote:

On Mon, Jun 29, 2026, at 12:27, Lynn wrote:

On Mon, Jun 29, 2026 at 2:20 AM Rob Landers <rob@getswytch.com> wrote:

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

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:

it would require types on the input parameters to disambiguate between arguments and properties

it gets weird if you don’t specify a default value for the property and makes it ambiguous as a constructor

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.

Nick · June 29, 2026, 11:42am

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

···

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.

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.

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

–

Cheers
Nick

Rowan_Tommins_IMSoP · June 29, 2026, 12:07pm

On 29 June 2026 11:52:45 BST, Rob Landers <rob@getswytch.com> wrote:

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]

Rob_Landers1 · June 29, 2026, 1:35pm

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.

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.

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.

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.

— Rob

–

Cheers
Nick

— Rob

Crell · June 29, 2026, 4:40pm

On Mon, Jun 29, 2026, at 5:52 AM, Rob Landers wrote:

On Mon, Jun 29, 2026, at 12:27, Lynn wrote:

On Mon, Jun 29, 2026 at 2:20 AM Rob Landers <rob@getswytch.com> wrote:

__
Hello internals,

I'd like to put forward Primary Constructors <PHP: 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

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

Crell · June 29, 2026, 4:59pm

On Sun, Jun 28, 2026, at 7:17 PM, Rob Landers wrote:

Hello internals,

I'd like to put forward Primary Constructors
<PHP: 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

Rowan_Tommins_IMSoP · June 29, 2026, 5:11pm

On 29 June 2026 17:40:29 BST, Larry Garfield <larry@garfieldtech.com> wrote:

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]

Eric_Norris · June 29, 2026, 6:44pm

On Mon, Jun 29, 2026 at 2:01 PM Larry Garfield <larry@garfieldtech.com> wrote:

On Sun, Jun 28, 2026, at 7:17 PM, Rob Landers wrote:
> Hello internals,
>
> I'd like to put forward Primary Constructors
> <PHP: 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.

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.

Seifeddine_Gmati · June 29, 2026, 6:54pm

On Mon, 29 Jun 2026 at 01:18, Rob Landers <rob@getswytch.com> wrote:

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.

Tim_Dusterhus · June 29, 2026, 7:04pm

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

Tim_Dusterhus · June 29, 2026, 7:07pm

Hi

Am 2026-06-29 02:17, schrieb Rob Landers:

I'd like to put forward Primary Constructors <PHP: 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

Rob_Landers1 · June 29, 2026, 7:08pm

On Mon, Jun 29, 2026, at 20:54, Seifeddine Gmati wrote:

On Mon, 29 Jun 2026 at 01:18, Rob Landers <rob@getswytch.com> wrote:

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.

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