Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129912 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 66B9B1A00BC for ; Sat, 24 Jan 2026 18:09:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1769278195; bh=g2nyKOn12r3M99mQJmF4uPinu0tI2izOYxGtz54bZ0E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=EkOLTZ5w7VmPq57IWXXRSO+iRVwRRb+3KawA3s9ZgmonIFTwjLVTi4K/lT6OVznNL O+8+MAq6DlPqoLU4gBApS3yD7Y4vbJEhRXcehmrJnJDhKtWczV7m7cOIzHxGaLBjoi TkYPtGnFRQj6KdkMFBNsHaVDimC7mpS9YncNN3+Rq6FXHdDtrLzHVO6yh6EqMavfGl EzijQWWGGWl46vIijlbTbeX/mPg+5FPELqyzpoq/+d71wOHY7YFwetavWerH2TFpQz cNAi63s1v2K5wj7LsWAgOD9jl3GPGoClQw3uNCB/MIoiyCPMBkBtH4ukgriqpU95/x aLypNyb6JdVvw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id ADE6D1805E9 for ; Sat, 24 Jan 2026 18:09:54 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_50, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS, FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 24 Jan 2026 18:09:54 +0000 (UTC) Received: by mail-qk1-f176.google.com with SMTP id af79cd13be357-8c52c67f64cso332350685a.0 for ; Sat, 24 Jan 2026 10:09:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769278188; cv=none; d=google.com; s=arc-20240605; b=R0SpoR6QmZ5s+X8WM20zWOrba/5zFfHrgM6Tq124bmtmWURLHdCbUPUhcv3d2LyJJ/ svi1tyAqeqaFRAcfeUQ3fjpo4bN6xx4v90nDWU0QjAFjnXr1mbJYrYZsJgnZIMvebTuP vjOfInA0qysoK1izRfd9N4adm5/j+FSq/nHyCPSD4NbW/VtbE+2EtwSsuRnhMl4qVwwm D0g4FCA4v1FYz5E0NEcDcRVkIdJJolEb7/kRrtOjZgve6uTecSWJWeV1dUPPJhchgw5p pDn1Oy6wvWeu6YpHaulz3iAFdgZI0U1T3C9e6DB1pNL2uITM8KFHHAhmg0PO7em4lWWM in0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=KGiHBg3LfP6fj2fhi6fTcBB9d/vGTF6oABdLaG68dVY=; fh=Ofn+XpSLefQyxrNYeqFK5V6BgIEzMTvoqvpJ6/SQfuk=; b=I3M76hG2TNdGZbZ8veCiTzGdVgFQcCpPgNa3todENhEeOo98wxP+UyCoAvbCSjflde DvtTUSucusvg+JfrvO3W+7B4xC4WPNAg8tHEeFEHCDsmK68JVxF1JbSwn5pSZhzlv+uZ 7WFsMTb+BKL/byMkpkmNIlRpImI4j9Masb2xYGgUpE/vZlHxIuzGx9+tfSs95b+QQLUY LYlunAWKKQiVMAFJ+tJRQVT+Lg9sE5S9h/AsuVA3ym2RU7j0YL2SWsJAeRPE3OtEPraV sK7X7U+jcPmpfD3xoUgUwxWG6RLchOuSfg/9RICnzBx6yiGJurm1BppauoREjAdkFXrf Ca9A==; darn=lists.php.net ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769278188; x=1769882988; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KGiHBg3LfP6fj2fhi6fTcBB9d/vGTF6oABdLaG68dVY=; b=RvrMt20Q8UJRR8wrIrBQ4M47EiY8PvauybtWfJUnwUVXLLUE2eI0ScMPI/W4nopf+/ zoUzY07OVvOR7xWC2mudEA3ygCpdLbXEgdQywvjY2uq00qeHENOBC4cU5SW5mtqLOZOD AJUA0lv9XAGN5N/zfKIFiuX33KTWYP2bkaGmGCywmW1w7cLwX4jQvgXr/3074rrKh3sI YudTWPH/BKmKopUCf5++bWcvaIzL0JtAy1HufUH7zpIr1Bq5LZyoJS9wQMLRw/CDjSqc 31valoUZYVDQFyuhtopsjVqXde1kOsrMuu8O24OtVVo7+eG7gQCQYNQP6OuI1Gho5O6q 4aWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769278188; x=1769882988; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KGiHBg3LfP6fj2fhi6fTcBB9d/vGTF6oABdLaG68dVY=; b=hInOFltThKLdmFvefvbAyFF0azRZmRjwl7jQ2EjInvXgROGLZRDP0vlHkzwXxbCeKj YFUm6Fyskp4Nmm10/wlnV/njLvX+nfQfDPaN8ovtxHjebs4+XssUxNnIvLVMerYuiDFM tb1fBqUdSWa85N5iORHWKCDZfU/4FDZh1KqigRgBuCWuLhaYl47aMvrrKq9Iheo6BQM7 Wjyn8uXq0rF727wsqF1YE4+3e6sTgxzYsrieW6+RCShqcvn+cihnnDHPsupaASSl+Z6N 8ZD6qzvcy7LITu8JyCOwvWK9/Big2l39HcUCBh+oUXOQhBCzz9nSBd42IFiF2+6tU2w9 2ZQw== X-Gm-Message-State: AOJu0Ywx3ukrkgYtEBFAEHqMdk4Ps03n9BuB9vlFL7E1y8HrIttsEh34 7G7rr7cUc/5mDXbNzKFX3q1sp3AgCsqHsyr+6MSL+WzwKnGiB7S16Hh+98nkyJu9De0eeacJ5Cc uexvMj3oYDtAw4/SitsKryTehjpaChqHxheOMfx0= X-Gm-Gg: AZuq6aLN8CgoTMQnpoqXKe+41vMIhgEEgyljWx/DmuMX2cVERPozsz4tSLryFQ4utws iV9ttuDpZ4/YhstLUWecJLIhrfHPNTU0DWrEd/HuVFF7DIr4wPRqWNmJGSa/AtYYXy6SfYy88nB /0uNU2fM4DKte9hkhZzyI6N/q0Hr0VjP0Ck9Pb0nX2agS6GIQNTKWGzVdiJBdXe31d0P9iWQBC2 U5AbE7e0/8z2YPbtfENwiF9ElrtTpzes4Bk9WYBxnfOx4tnz7ru2JywgzTUDOKZoyWiWRT9n3mm Ruc57/6WOk5SDp6/Up565jbEXu9V4ZYKb0Jf7N4HCvKw+cFntygvNds9 X-Received: by 2002:a05:620a:4586:b0:8c5:391f:1db7 with SMTP id af79cd13be357-8c6e91fb36dmr572686685a.64.1769278188350; Sat, 24 Jan 2026 10:09:48 -0800 (PST) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: <077e27345a1f5b7969c114684aede7e8@bastelstu.be> <85e10caa-f577-4f8f-a93d-955348b67013@app.fastmail.com> In-Reply-To: <85e10caa-f577-4f8f-a93d-955348b67013@app.fastmail.com> Date: Sat, 24 Jan 2026 19:09:38 +0100 X-Gm-Features: AZwV_Qh-So0TY8IZCiadT0hy-P1pSNVX5eAJ8Ysc1cjHQLh-8GhoHJPHDjOoBwY Message-ID: Subject: Re: [PHP-DEV] [RFC] Allow Reassignment of Promoted Readonly Properties in Constructor To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="000000000000ecf4070649262dbb" From: nicolas.grekas+php@gmail.com (Nicolas Grekas) --000000000000ecf4070649262dbb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le ven. 23 janv. 2026 =C3=A0 16:59, Larry Garfield = a =C3=A9crit : > On Thu, Jan 22, 2026, at 11:26 AM, Nicolas Grekas wrote: > > Thanks Tim, Larry, > > > > Le jeu. 22 janv. 2026 =C3=A0 17:21, Tim D=C3=BCsterhus a =C3=A9crit > : > >> Hi > >> > >> Am 2026-01-22 16:33, schrieb Nicolas Grekas: > >> > Here is a new RFC for you to consider: > >> > https://wiki.php.net/rfc/promoted_readonly_constructor_reassign > >> > >> Thank you. I have taken a look and have the following notes (for now): > >> > >> 1. In the Problem Statement: =E2=80=9COption 2: Use default parameter > >> expressions (limited):=E2=80=9D > >> > >> The example seems incorrect to me, particularly the =E2=80=9C// Cannot= use $x > in > >> default expression for $x=E2=80=9D comment doesn't make sense. Can you= check > you > >> pasted in the correct snippet? > >> > >> 2. Within the proposal: =E2=80=9CThe reassignment must occur directly = in the > >> constructor body of the declaring class (not via method calls, > closures, > >> or other indirect means)=E2=80=9D > >> > >> I believe this is inconsistent with `__clone()` where the readonly > >> property remains unlocked until the end of `__clone()` (and is then > >> locked). > >> > >> I'm seeing it is explained further below as =E2=80=9CThis restriction = exists > >> because the check verifies that the current executing function is the > >> constructor of the declaring class. When a method or closure executes, > >> the current function changes, even if it was called from the > >> constructor=E2=80=9D, which effectively means that you defined the sem= antics > >> based on the implementation instead of the other way around, which I > >> consider problematic from a language design PoV. I'm positive it is > >> possible to find a better implementation here. > >> > >> 3. Within the =E2=80=9CRFC Impact=E2=80=9D section you removed the =E2= =80=9CEcosystem=E2=80=9D > >> subsection from the template. > >> > >> I believe mentioning the ecosystem impact is relevant here. This chang= e > >> will likely require adjustments to static analysis tools and IDEs to > not > >> point out the now-valid assignment as an error. > >> > >> 4. As per the updated RFC policy. > >> > >> Please already include the (closed) voting doodle in the RFC so there > is > >> no ambiguity here. Don't forget to include the =E2=80=9CAbstain=E2=80= =9D option. My > >> suggested title would just be using the RFC title followed by a > >> questionmark :-) > >> > >> And please add a link to the list archives to the References section > >> (it's required per the policy and useful for future research). For you= r > >> convenience, the correct link is this: > >> https://news-web.php.net/php.internals/129851 > >> > > > > > > RFC text updated to account for your comments Tim, good catch and > > thanks for the help around RFC processes. > > > > About the assignment rule, Larry and you have the same reaction, so let > > me take this as a good description of the most expected behavior by the > > community ;-) > > I made the more restricted rule because I thought I should start with > > the stricter rule, and I get that would also be surprising somehow, so > > let's relax that. > > > > PR (and RFC) updated with the new logic, similar to __clone (and as > > boring as it can be ;P ) > > > > Cheers, > > Nicolas > > Boring is good in this case. :-) I like the updates. I only have two > remaining quibbles. > > > All other readonly semantics remain unchanged (no modification outside > constructor, no unsetting, etc.) > > As previously stated, "no modification outside constructor" is not, and > has never been, part of the language semantics of readonly. In fact, the > RFC has been updated now such that updates outside of the constructor are > allowed, provide the constructor is in the call stack. Please remove tha= t > clause, as it is incorrect. > How would you phrase this? To me, point 3 above makes this clear: "The reassignment must occur while a constructor of the object is on the call stack (methods and closures called from the constructor are allowed)" Then, point 7: "All other readonly semantics remain unchanged (no modification outside constructor, no unsetting, etc.)" has enough context to me to be clear. No? --000000000000ecf4070649262dbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le=C2=A0ven. 23= janv. 2026 =C3=A0=C2=A016:59, Larry Garfield <larry@garfieldtech.com> a =C3=A9crit=C2=A0:
On Thu, Jan 22, 2026, a= t 11:26 AM, Nicolas Grekas wrote:
> Thanks Tim, Larry,
>
> Le jeu. 22 janv. 2026 =C3=A0 17:21, Tim D=C3=BCsterhus <tim@bastelstu.be> a =C3= =A9crit :
>> Hi
>>
>> Am 2026-01-22 16:33, schrieb Nicolas Grekas:
>> > Here is a new RFC for you to consider:
>> > https://wiki.php.net/rf= c/promoted_readonly_constructor_reassign
>>
>> Thank you. I have taken a look and have the following notes (for n= ow):
>>
>> 1. In the Problem Statement: =E2=80=9COption 2: Use default parame= ter
>> expressions (limited):=E2=80=9D
>>
>> The example seems incorrect to me, particularly the =E2=80=9C// Ca= nnot use $x in
>> default expression for $x=E2=80=9D comment doesn't make sense.= Can you check you
>> pasted in the correct snippet?
>>
>> 2. Within the proposal: =E2=80=9CThe reassignment must occur direc= tly in the
>> constructor body of the declaring class (not via method calls, clo= sures,
>> or other indirect means)=E2=80=9D
>>
>> I believe this is inconsistent with `__clone()` where the readonly=
>> property remains unlocked until the end of `__clone()` (and is the= n
>> locked).
>>
>> I'm seeing it is explained further below as =E2=80=9CThis rest= riction exists
>> because the check verifies that the current executing function is = the
>> constructor of the declaring class. When a method or closure execu= tes,
>> the current function changes, even if it was called from the
>> constructor=E2=80=9D, which effectively means that you defined the= semantics
>> based on the implementation instead of the other way around, which= I
>> consider problematic from a language design PoV. I'm positive = it is
>> possible to find a better implementation here.
>>
>> 3. Within the =E2=80=9CRFC Impact=E2=80=9D section you removed the= =E2=80=9CEcosystem=E2=80=9D
>> subsection from the template.
>>
>> I believe mentioning the ecosystem impact is relevant here. This c= hange
>> will likely require adjustments to static analysis tools and IDEs = to not
>> point out the now-valid assignment as an error.
>>
>> 4. As per the updated RFC policy.
>>
>> Please already include the (closed) voting doodle in the RFC so th= ere is
>> no ambiguity here. Don't forget to include the =E2=80=9CAbstai= n=E2=80=9D option. My
>> suggested title would just be using the RFC title followed by a >> questionmark :-)
>>
>> And please add a link to the list archives to the References secti= on
>> (it's required per the policy and useful for future research).= For your
>> convenience, the correct link is this:
>> https://news-web.php.net/php.internals/129851<= /a>
>>
>
>
> RFC text updated to account for your comments Tim, good catch and
> thanks for the help around RFC processes.
>
> About the assignment rule, Larry and you have the same reaction, so le= t
> me take this as a good description of the most expected behavior by th= e
> community ;-)
> I made the more restricted rule because I thought I should start with =
> the stricter rule, and I get that would also be surprising somehow, so=
> let's relax that.
>
> PR (and RFC) updated with the new logic, similar to __clone (and as > boring as it can be ;P )
>
> Cheers,
> Nicolas

Boring is good in this case. :-)=C2=A0 I like the updates.=C2=A0 I only hav= e two remaining quibbles.

> All other readonly semantics remain unchanged (no modification outside= constructor, no unsetting, etc.)

As previously stated, "no modification outside constructor" is no= t, and has never been, part of the language semantics of readonly.=C2=A0 In= fact, the RFC has been updated now such that updates outside of the constr= uctor are allowed, provide the constructor is in the call stack.=C2=A0 Plea= se remove that clause, as it is incorrect.

<= div>How would you phrase this?

--000000000000ecf4070649262dbb--