Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129917 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 B4B591A00BC for ; Sat, 24 Jan 2026 21:00:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1769288462; bh=X3GNdeQp7MogU3jIlaKznEGPNUt0QNxHi6ybMsYll2o=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=WuD/7u4vnmPL3KZhB11E+po5u1W6yoc/r1Gh/tXa51e1ufVkIHc4Vp6isBc7NHXVI 15ITAmN+ajlrE8IltIhV6w0tnVmHUtWcCAmdfZGuYTTuP6P/oCGOxkqXMxKN7GfYG0 z+yAin4muK5eWBbQESUfb/7nTYEXVGAczn8dzxPoYV7YPVFvyexF8w1bFbStt2mnIm Q0IlQpYHclQqvlQLOj0DY2ecChD49aEGm3O9k1iQfC9p4WIvJ3uv6C9Pq/pZP8MHR1 VQBiPkT4Am5KRVS6vhpkmyUHpw0O30GPpHdnX+vQ0GptICYC+5mJ/M0KOogDbASZ4m 2m0Np7xd93qXw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3205B180047 for ; Sat, 24 Jan 2026 21:01:01 +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_FONT_LOW_CONTRAST,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-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (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 21:01:00 +0000 (UTC) Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-658072a4e56so6716894a12.0 for ; Sat, 24 Jan 2026 13:00:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769288454; cv=none; d=google.com; s=arc-20240605; b=C7fDPZPjkzv++oWw0BiV0niL6zNKaD/O8DsbQoCgnZi6f118nqbsFJl8tmvFraZ3iy MDfBWoTENaSHp3LDomg8hFJYzG7xrY+bLhEP3PHSPsuodktsQxJ2ybnASpH1WPlNTn12 pk7W1/g+Taoa7DGq9ouBRNifiV9hxDQYsUAVbpXuKkxiF1zkWweEK0vD1BsPLrMNp7zi HTHXjN5M5IMlLODe4JBcDW1RDu5wYB+R9R556c2nGLIfIQghgBI1Xe4bOvWxYndzmAs4 uu4eGmBwU8n6nbCuSO7n++4BoFefpDC4r16up8qFWJQl0HV3O6kOHFkR7VlaEkIgOiCm QR7Q== 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=X3GNdeQp7MogU3jIlaKznEGPNUt0QNxHi6ybMsYll2o=; fh=+7N00XCCLPVMPg6QRoaRwczbvrIsugRKJIMH5bjQG8c=; b=itTBPOR/fJc97qDYzJfC5AQ1inSioGyZw0lfWs0vhqltJ1mAqxMJiGaOyH4SScnCSN 6uCAoyHGxw26UGFp3TIU/SOt8MgiN8OVxGmlJXfS+fLnrwj5P3Dpcwy2KpfXTtmbCVAQ JtXsm43JwDax7cfCPwRWMOsnnSxT740tCvCsl5lEgkRauChGwpX/HdqYQW4sLhMpntwj TKHUgm6yQGv6DMjFGLQMI6ios8JmQpSFBoF5JB6Pa7Aqp3b11bA25XVUdB4tA/6GFHhI enlz3hG9L/F4BUHEBbpUMDvGdHGjj9rIa07velkoIIXfhECK3hqZDcH+PLSK9vIzL/i1 4V6w==; 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=1769288454; x=1769893254; 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=X3GNdeQp7MogU3jIlaKznEGPNUt0QNxHi6ybMsYll2o=; b=KCCCCrRSXN5Dk3pxqCX9R7CIsWNbPfDD/HW7o9N601pBFPntLN0w0Y4w6NmtqhMKJD BDzI4+UEAa69zbtLxoEwZ4ESRVT34Kruwc4KoHKkG16bJdjqzKGAFrutLridIE1WSuMv lSlNDMvcx+BlqPPf35rOhh79Md1VNl7H8UvYjgNNua8IxUOsY0ncS5SF4KP0pecEe9wJ AqX0Rl5Mkx9RzdSCYpN4jICgmgzza26KMjNnYfT3g0t3NB9jONFt0YWba3GkHet1zFdo S5jpYAtqnGPU6nVrngp7eF+pbXukALpSAV5TJek+TrZo05iGIVRRF0JNaKi+mesvzl7o yHBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769288454; x=1769893254; 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=X3GNdeQp7MogU3jIlaKznEGPNUt0QNxHi6ybMsYll2o=; b=JZCujKudOj41x189IcY7wwFea9vgZ+ml4Cb4f+xW9tWXzpsZ2VSKGAhF4MxdBM58ZC yTZqRQA7mfBRSENjMbsQ+7Ee8Ii5IQAMMSPrK/EkGVh7SR5si9X7Tbqa8hNroDJuVhth DsSiGnfhTqRidGWJqmjW9zcrERlEogIAzVHNAXpv4EEIRL4jaE0OlE4IGa0SsLJ5xDpV ehU0QZ13V51rRlsEG3dSVoPhIVMWrBkd/hBvjuQRo+B82Na0JS4egc5oPvWD1HD6BAfN WYRmQZghiqSf3yhYs6Vn7SDESWhoUWUGKEfHCfw7/QRQyFEx5lCIj4uAefL5HJAw7FoR 2B4Q== X-Forwarded-Encrypted: i=1; AJvYcCUurBRZkAVIKPi/SYC/nu0xa/0ARCPF2dStjPZpSn89VG14HpobfSP38linwwV1+iZZnIG9K058lZo=@lists.php.net X-Gm-Message-State: AOJu0YzS80AusHXYSpCNSZU/by+nTEprpqC+NGndFMeFo0naglvBp2tf cj7piOXYbgrM3flDtbR+Q0X3M/xFfrpY0kcs19Ic0t595Vx5tsdH2YL8ytjHY8V4Huj4Hhh/vaq IqWW1xUpUgxcjUapVQU0sqsSn9IRD+hY= X-Gm-Gg: AZuq6aJcp0Ku6L1Gk/z7nWcd0OT3eONXaCRB1kpgsej/g0evrJyBsO6WdovFuKniUw/ kcLazrH30yFX+r7Ci1HpGWlhKdVSEUBBp5+sFRVkBnjWVWPIqXsGNfKg5aJr3d8XF5FyuuQVK7T hXhgSQcNhoxNMsTO/nkE6uhUkB5TaGbq9HsXe1EEVpdSv4DCXi4i4EVs8+zWl1tUthAK3eZBHbW V0RnyRoLDlNk3qSS6pCdRkwHtZRVenSf7oxqZ/jJSae83oA5mpdylCMzwQ8H/M/6HZx4/Y= X-Received: by 2002:a17:907:3f17:b0:b87:117f:b6ed with SMTP id a640c23a62f3a-b885acca601mr529038466b.21.1769288454190; Sat, 24 Jan 2026 13:00:54 -0800 (PST) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: <37dfe05b2abdbf6fda4789ddc5435c48@bastelstu.be> In-Reply-To: <37dfe05b2abdbf6fda4789ddc5435c48@bastelstu.be> Date: Sat, 24 Jan 2026 22:00:42 +0100 X-Gm-Features: AZwV_QgCDfUzZcKSIckU2g5WgQhwqJskGro6e5uvfawNRFkuLjWNxX_RRKgMf9s Message-ID: Subject: Re: [PHP-DEV] [VOTE] let construct (Block Scoping) To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= Cc: =?UTF-8?Q?Benjamin_Au=C3=9Fenhofer?= , php internals , Seifeddine Gmati Content-Type: multipart/alternative; boundary="000000000000d13a58064928911e" From: arnaud.lb@gmail.com (Arnaud Le Blanc) --000000000000d13a58064928911e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Le sam. 24 janv. 2026 =C3=A0 18:35, Tim D=C3=BCsterhus a= =C3=A9crit : > Am 2026-01-24 15:13, schrieb Arnaud Le Blanc: > >> and thats what people writing cleanup critical code rely on already. > >> This gives a much nicer syntax. > > > > In my experience, relying on this causes occasional bugs that are > > unusually difficult to address (and to avoid in the first place). > > The RFC lists 4 possible use cases within the example section: I agree that the RFC adresses 3 of these use cases, but I regret that the pitfall in the last one is being dismissed or minimized, while claiming to address that use case. There is enough evidence in other languages that the pitfall is real and common, as features claiming to address the use case are designed explicitly to avoid it. This leaves the locking example This is a simple one, but most code will send the scoped resource to other functions to perform anything useful, increasing the risk of capture. >> The future scope lists improvements as next steps, like the error when > >> RC > 1 or Disposable interfaces, this is a first step towards > >> something that is missing dearly. > > > > Unfortunately these improvements won't make it because they will be > > breaking changes. > > This is false. We would not list anything as "Future Scope" when it would be a breaking change. Both the RC > 1 and the Disposable interface > would require the author of the resource class to add an interface for > the corresponding functionality to become active and would therefore be > fully opt-in. Adding new symbols (incl. interfaces) to PHP is not > considered a breaking change as per our policy: > > https://github.com/php/policies/blob/main/release-process.rst#backward-co= mpatibility > . > The issue is that implementing Disposable on existing objects after the fact is a BC break as by then some code may rely on the fact that disposal is not enforced. This precludes making any exiting object (or streams) Disposable if that interface is introduced later, because this might break people=E2=80=99s code. Making it opt-in in the let() syntax is a potential = solution to that, but it=E2=80=99s error prone. > For disposal, only if we decide so. The RFC proposes to introduce > > block scoping, and could have made the decision to deterministically > > dispose of values as they go out of scope. > > See above: This would possibly break at least one of the presented use > cases of the RFC. As you said this would be opted in by implementing Disposable. > The RFC refers to similar features in Python and Hack, with the same > > basic syntax, both of which use reference counting as primary garbage > > collection mechanism, yet disposal is deterministic in this context. > > The "References" section is non-normative with regard to the proposal > itself and just supplies supplementary information. My previous email > provides further context to the listed references: > https://news-web.php.net/php.internals/129202. I know, but making comparisons is natural as the RFC claims to address the same use cases. Based on the previous thread it feels like the design was adapted to borrow principles from Rust (objects can be disposed only when unreachable), but PHP doesn=E2=80=99t have features that would make this re= liable, like explicit lifetimes. I think that the way that languages closer to PHP implement this use case would fit PHP better. Best Regards, Arnaud --000000000000d13a58064928911e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Le=C2= =A0sam. 24 janv. 2026 =C3=A0 18:35, Tim D=C3=BCsterhus <tim@bastelstu.be> a =C3=A9crit= =C2=A0:
Am 2026-01-24 15:13, schrieb Arnaud Le Blanc:
>> and thats what people writing cleanup critical code rely on alread= y.
>> This gives a much nicer syntax.
>
> In my experience, relying on this causes occasional bugs that are
> unusually difficult to address (and to avoid in the first place).

The RFC lists 4 possible use cases within the example section:
=

I agree= that the RFC adresses 3 of these use cases, but I regret that the pitfall = in the last one is being dismissed or minimized, while claiming to address = that use case.=C2=A0There is enough evidence in other languages that = the pitfall is real and common, as features claiming to address the use cas= e are designed explicitly to avoid it.

This leaves the loc= king example

=
This is a=C2=A0simple one, but most code will send the sc= oped resource to other functions to perform anything useful, increasing the= risk of capture.

>> The future scope lists improvements as= next steps, like the error when=C2=A0
>> RC > 1 or Disposable interfaces, this is a first step towards <= br> >> something that is missing dearly.
>
> Unfortunately these improvements won't make it because they will b= e
> breaking changes.

This is false. We would not list anything as "Future Scope" when = it=C2=A0
would be a breaking change. Both the RC > 1 and the Disposable interface=
would require the author of the resource class to add an interface for
the corresponding functionality to become active and would therefore be fully opt-in. Adding new symbols (incl. interfaces) to PHP is not
considered a breaking change as per our policy:
https://github.c= om/php/policies/blob/main/release-process.rst#backward-compatibility.

The issue is that implementing D= isposable on existing objects after the fact is a BC break as by then some = code may rely on the fact that disposal is not enforced.=C2=A0This precludes making any exiting object (or st= reams) Disposable if that interface is introduced later, because this might= break people=E2=80=99s code. Making=C2=A0it opt-in in the let() syntax is a potential solution to that, but = it=E2=80=99s error prone.

> For disposal, only if we decide so. The RFC proposes to introduce
> block scoping, and could have made the decision to deterministically > dispose of values as they go out of scope.

See above: This would possibly break at least one of the presented use
cases of the RFC.

=
As you said this would be opted in by implementing D= isposable.

> The RFC refers to similar features in Python and Hack, with the same > basic syntax, both of which use reference counting as primary garbage<= br> > collection mechanism, yet disposal is deterministic in this context.
The "References" section is non-normative with regard to the prop= osal
itself and just supplies supplementary information. My previous email
provides further context to the listed references:
https://news-web.php.net/php.internals/129202.

I know, but making co= mparisons is natural as the RFC claims to address the same use cases. Based= on the previous thread it feels=C2=A0like the design was adapted to borrow= principles from Rust=C2=A0(objects can be disposed=C2=A0only when unreacha= ble), but PHP doesn=E2=80=99t have=C2=A0features=C2=A0that would make this = reliable, like explicit lifetimes. I think that the way that languages clos= er to PHP=C2=A0implement this use case=C2=A0would fit PHP better.

Best Regards,
Arnaud

--000000000000d13a58064928911e--