Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129950
Precedence: list
MIME-Version: 1.0
References: <CAOWwgp=JtbTSVCv9z=QGx9yS=8G72L-hcAjcOj33eEMLB0zfvg@mail.gmail.com>
 <FBFBB33D-7135-49B1-9F91-5E10F3248AB1@gmail.com>
In-Reply-To: <FBFBB33D-7135-49B1-9F91-5E10F3248AB1@gmail.com>
Date: Thu, 29 Jan 2026 17:36:11 +0100
Message-ID: <CAOWwgpkdXaTBx+6Ke8dw=oTOqFUZfw30FTNYzxQDA4EYjvGiVg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Allow Reassignment of Promoted Readonly
 Properties in Constructor
To: Claude Pache <claude.pache@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fa772b0649897414"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000fa772b0649897414
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Claude,

Le mer. 28 janv. 2026 =C3=A0 19:53, Claude Pache <claude.pache@gmail.com> a
=C3=A9crit :

>
>
> Le 22 janv. 2026 =C3=A0 16:33, Nicolas Grekas <nicolas.grekas+php@gmail.c=
om> a
> =C3=A9crit :
>
> Dear all,
>
> Here is a new RFC for you to consider:
> https://wiki.php.net/rfc/promoted_readonly_constructor_reassign
>
> As a quick intro, my motivation for that RFC is that I find it quite
> annoying that readonly properties play badly with CPP (constructor proper=
ty
> promotion).
>
> Doing simple processing of any argument before assigning it to a readonly
> property forces opting out of CPP.
>
> This RFC would allow setting once a readonly property in the body of a
> constructor after the property was previously (and implicitly) set using
> CPP.
>
> This allows keeping property declarations in their compact form while
> still enabling validation, normalization, or conditional initialization.
>
> Cheers,
> Nicolas
>
>
>
> Hi,
>
> I am reserved about the proposal, because this style of using CPP and
> processing the value after the fact tends to favour brevity at the expens=
e
> of precision and clarity. Let=E2=80=99s illustrate that with two examples=
 from the
> RFC. First:
>
> ```php
> class Config {
>     public function __construct(
>         public readonly ?string $cacheDir =3D null,
>     ) {
>         $this->cacheDir ??=3D sys_get_temp_dir() . '/app_cache';
>     }
> }
> ```
>
> As of today you can write:
>
> ```php
> class Config {
>     public readonly string $cacheDir;
>
>     public function __construct(
>         ?string $cacheDir =3D null,
>     ) {
>         $this->cacheDir =3D $cacheDir ??=3D sys_get_temp_dir() . '/app_ca=
che';
>     }
> }
> ```
>
> Note that the property is marked as non-nullable, a precision that may be
> useful for both programmers and static analysers. With your proposal, the=
re
> is no way to keep this information.
>
>
> The second example is similar:
>
> ```php
> class User {
>     public function __construct(
>         public readonly string $email,
>     ) {
>         if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
>             throw new InvalidArgumentException('Invalid email');
>         }
>         $this->email =3D strtolower($email);  // Normalize
>     }
> }
> ```
>
> As of today, it can be written as:
>
> ```php
> class User {
>
>     /** @var non-empty-string & lowercase-string */
>     public readonly string $email;
>
>     public function __construct(
>         string $email,
>     ) {
>         if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
>             throw new InvalidArgumentException('Invalid email');
>         }
>         $this->email =3D strtolower($email);  // Normalize
>     }
> }
> ```
>
> With your proposal, there is no obvious way to keep the additional
> information provided in the phpdoc. Maybe we could imagine something like
> that:
>
> ```php
> class User {
>     /**
>      * @param string $email the e-mail address as provided
>      */
>     public function __construct(
>         /** @var non-empty-string & lowercase-string the normalised e-mai=
l
> address */
>         string $email,
>     ) {
>         if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
>             throw new InvalidArgumentException('Invalid email');
>         }
>         $this->email =3D strtolower($email);  // Normalize
>     }
> }
> ```
>
> but it is obviously clearer (at least to my eyes) to keep the property an=
d
> the constructor parameter separate.
>
> One additional thought: Readonly properties carry a constraint that is
> annoying at first, but that is finally beneficial for the clarity of code
> that is written. When initialising such a property with something more
> complex than what can be comfortably written in a single expression, I am
> forced to write the intermediate results in a temporary variable and to
> assign the final value to the property at the end of the process, instead
> of transforming gradually the value of the property. The resulting code i=
s
> a few lines longer, but it is no less clear, even it is often clearer,
> because it is obvious that this specific assignment supplies the final
> value of the property, and there is no need to look further down to see
> whether the value will undergo some additional transformations. As of
> today, this =E2=80=9Cfinal assignment=E2=80=9D may be part of the constru=
ctor signature;
> with this RFC implemented, one can no longer know at a glance whether thi=
s
> assignment is =E2=80=9Cfinal=E2=80=9D.
>
> (Also I sympathise with Larry: rigid coding styles and static analysers=
=E2=80=99
> promoted =E2=80=9Cgood practices=E2=80=9D add problematic limitations tha=
t are not part of
> the semantics of language. I prefer disabling checks in PHPStan rather th=
an
> downgrading to non-safe mutable properties and/or writing getters around
> them.)
>
>
>
Thank you for the thoughtful feedback. You raise valid points about type
precision and PHPDoc annotations being harder to express with CPP.

I've added a "Design Considerations" section to the RFC acknowledging these
tradeoffs and clarifying when traditional declaration remains preferable
(type narrowing, detailed annotations, complex initialization) vs. when CPP
+ reassignment fits well (simple transformations like trim/lowercase,
validation with fallback).

The key point is: this RFC adds an option, it doesn't mandate any style. If
"final at declaration" clarity matters for a specific property, traditional
declaration remains available.

Regarding the "final assignment" concern: an earlier iteration considered
restricting reassignment to only the constructor body (no other methods
could reassign), but this was ruled out,  at least for consistency with
__clone().

Cheers,
Nicolas

--000000000000fa772b0649897414
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Claude,</div><br><div class=3D"gmail_q=
uote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0m=
er. 28 janv. 2026 =C3=A0=C2=A019:53, Claude Pache &lt;<a href=3D"mailto:cla=
ude.pache@gmail.com">claude.pache@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br id=3D"m_-8=
75456883127790013lineBreakAtBeginningOfMessage"><div><br><blockquote type=
=3D"cite"><div>Le 22 janv. 2026 =C3=A0 16:33, Nicolas Grekas &lt;<a href=3D=
"mailto:nicolas.grekas%2Bphp@gmail.com" target=3D"_blank">nicolas.grekas+ph=
p@gmail.com</a>&gt; a =C3=A9crit :</div><br><div><div dir=3D"ltr"><div>Dear=
 all,</div><div><br></div><div>Here is a=C2=A0new RFC for you to consider:<=
/div><div><a href=3D"https://wiki.php.net/rfc/promoted_readonly_constructor=
_reassign" target=3D"_blank">https://wiki.php.net/rfc/promoted_readonly_con=
structor_reassign</a></div><div><br></div><div>As a quick intro, my motivat=
ion for that RFC is that I find it quite annoying that readonly properties =
play badly with CPP (constructor property promotion).</div><div><br>Doing s=
imple processing of any argument before assigning it to a readonly property=
 forces opting out of CPP.<br><br>This RFC would allow setting once a reado=
nly property in the body of a constructor after the property was previously=
 (and implicitly) set using CPP.<br><br></div>This allows keeping property =
declarations in their compact form while still enabling validation, normali=
zation, or conditional initialization.<br><br><div>Cheers,</div><div>Nicola=
s</div></div>
</div></blockquote></div><br><div><br></div><div><div>Hi,</div><div><br></d=
iv><div>I am reserved about the proposal, because this style of using CPP a=
nd processing the value after the fact tends to favour brevity at the expen=
se of precision and clarity. Let=E2=80=99s illustrate that with two example=
s from the RFC. First:</div><div><br></div><div>```php</div><div>class Conf=
ig {</div><div>=C2=A0 =C2=A0 public function __construct(</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 public readonly ?string $cacheDir =3D null,</div><div>=
=C2=A0 =C2=A0 ) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 $this-&gt;cacheDir =
??=3D sys_get_temp_dir() . &#39;/app_cache&#39;;</div><div>=C2=A0 =C2=A0 }<=
/div><div>}</div><div>```</div><div><br></div><div>As of today you can writ=
e:</div><div><br></div><div>```php</div><div>class Config {</div><div>=C2=
=A0 =C2=A0 public readonly string $cacheDir;</div><div><br></div><div>=C2=
=A0 =C2=A0 public function __construct(</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 ?string $cacheDir =3D null,</div><div>=C2=A0 =C2=A0 ) {</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 $this-&gt;cacheDir =3D $cacheDir ??=3D sys_get_tem=
p_dir() . &#39;/app_cache&#39;;</div><div>=C2=A0 =C2=A0 }</div><div>}</div>=
<div>```</div><div><br></div><div>Note that the property is marked as non-n=
ullable, a precision that may be useful for both programmers and static ana=
lysers. With your proposal, there is no way to keep this information.</div>=
<div><br></div><div><br></div><div>The second example is similar:</div><div=
><br></div><div>```php</div><div>class User {</div><div>=C2=A0 =C2=A0 publi=
c function __construct(</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 public readon=
ly string $email,</div><div>=C2=A0 =C2=A0 ) {</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 throw new InvalidArgumentException(&=
#39;Invalid email&#39;);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 $this-&gt;email =3D strtolower($email); =C2=A0/=
/ Normalize</div><div>=C2=A0 =C2=A0 }</div><div>}</div><div>```</div><div><=
br></div><div>As of today, it can be written as:</div><div><br></div><div>`=
``php</div><div>class User {</div><div><br></div><div>=C2=A0 =C2=A0 /** @va=
r non-empty-string &amp; lowercase-string */</div><div>=C2=A0 =C2=A0 public=
 readonly string $email;</div><div><br></div><div>=C2=A0 =C2=A0 public func=
tion __construct(</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 string $email,</div=
><div>=C2=A0 =C2=A0 ) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!filter_v=
ar($email, FILTER_VALIDATE_EMAIL)) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 throw new InvalidArgumentException(&#39;Invalid email&#39;);<=
/div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 $this-&gt;email =3D strtolower($email); =C2=A0// Normalize</div><div>=
=C2=A0 =C2=A0 }</div><div>}</div><div>```</div><div><br></div><div>With you=
r proposal, there is no obvious way to keep the additional information prov=
ided in the phpdoc. Maybe we could imagine something like that:</div><div><=
br></div><div>```php</div><div>class User {</div><div>=C2=A0 =C2=A0 /**=C2=
=A0</div><div>=C2=A0 =C2=A0 =C2=A0* @param string $email the e-mail address=
 as provided</div><div>=C2=A0 =C2=A0 =C2=A0*/</div><div>=C2=A0 =C2=A0 publi=
c function __construct(</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 /** @var non-=
empty-string &amp; lowercase-string the normalised e-mail address */</div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 string $email,</div><div>=C2=A0 =C2=A0 ) {<=
/div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!filter_var($email, FILTER_VALIDA=
TE_EMAIL)) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 throw new =
InvalidArgumentException(&#39;Invalid email&#39;);</div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 }</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 $this-&gt;email =3D s=
trtolower($email); =C2=A0// Normalize</div><div>=C2=A0 =C2=A0 }</div><div>}=
</div><div>```</div><div><br></div><div>but it is obviously clearer (at lea=
st to my eyes) to keep the property and the constructor parameter separate.=
</div><div><br></div><div>One additional thought: Readonly properties carry=
 a constraint that is annoying at first, but that is finally beneficial for=
 the clarity of code that is written. When initialising such a property wit=
h something more complex than what can be comfortably written in a single e=
xpression, I am forced to write the intermediate results in a temporary var=
iable and to assign the final value to the property at the end of the proce=
ss, instead of transforming gradually the value of the property. The result=
ing code is a few lines longer, but it is no less clear, even it is often c=
learer, because it is obvious that this specific assignment supplies the fi=
nal value of the property, and there is no need to look further down to see=
 whether the value will undergo some additional transformations. As of toda=
y, this =E2=80=9Cfinal assignment=E2=80=9D may be part of the constructor s=
ignature; with this RFC implemented, one can no longer know at a glance whe=
ther this assignment is =E2=80=9Cfinal=E2=80=9D.</div><div><br></div><div>(=
Also I sympathise with Larry: rigid coding styles and static analysers=E2=
=80=99 promoted =E2=80=9Cgood practices=E2=80=9D add problematic limitation=
s that are not part of the semantics of language. I prefer disabling checks=
 in PHPStan rather than downgrading to non-safe mutable properties and/or w=
riting getters around them.)</div><div><br></div><div><br></div></div></div=
></blockquote><div><br></div><div>Thank you for the thoughtful feedback. Yo=
u raise valid points about type precision and PHPDoc annotations being hard=
er to express with CPP.</div><br>I&#39;ve added a &quot;Design Consideratio=
ns&quot; section to the RFC acknowledging these tradeoffs and clarifying wh=
en traditional declaration remains preferable (type narrowing, detailed ann=
otations, complex initialization) vs. when CPP + reassignment fits well (si=
mple transformations like trim/lowercase, validation with fallback).<br><br=
>The key point is: this RFC adds an option, it doesn&#39;t mandate any styl=
e. If &quot;final at declaration&quot; clarity matters for a specific prope=
rty, traditional declaration remains available.<br><br>Regarding the &quot;=
final assignment&quot; concern: an earlier iteration considered restricting=
 reassignment to only the constructor body (no other methods could reassign=
), but this was ruled out,=C2=A0=C2=A0at least=C2=A0for consistency with __=
clone().</div><div class=3D"gmail_quote gmail_quote_container"><br>Cheers,<=
/div><div class=3D"gmail_quote gmail_quote_container">Nicolas<br><br><div>=
=C2=A0</div></div></div>

--000000000000fa772b0649897414--