Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129959
Content-Type: multipart/alternative;
 boundary="------------fo0XxMb447gVEPvAfp3u9gyU"
Message-ID:
 <AM8P250MB0170756BF45C2EF00FDD7B27E29CA@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Date: Sat, 31 Jan 2026 04:55:18 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [VOTE] let construct (Block Scoping)
To: Marco Pivetta <ocramius@gmail.com>, =?UTF-8?Q?Tim_D=C3=BCsterhus?=
 <tim@bastelstu.be>
Cc: php internals <internals@lists.php.net>,
 Seifeddine Gmati <azjezz@carthage.software>
References: <bfea3ae503ea2a4d375da077ecef2097@bastelstu.be>
 <CADyq6sJonm8o4+BFph2zJO=oeAJpQXMRmOhnJpixRoq2UC2Y2g@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CADyq6sJonm8o4+BFph2zJO=oeAJpQXMRmOhnJpixRoq2UC2Y2g@mail.gmail.com>
Precedence: list
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AM8P250MB0170:EE_|DB4P250MB0831:EE_
X-MS-Office365-Filtering-Correlation-Id: 3cf889cd-17f5-4d5b-1275-08de607c8cee
X-MS-Exchange-SLBlob-MailProps:
	9IecXKUgicB5Y5xtj3Bi4po1AHQXatGh88q+xQ41W6khuVQb5LetJM5ltP8RI6MiKYDvDuM24Wy21vn9PMj7k3cDJe9V4DDTTtUiD60QGkG++RAOGwpUUP4yaJnGtxmZ/QpNkKwN38s/K03nJ7a/XsqyWviL8qqyAahhq31Bbv9z7DPgpzSFObItQ3X28LMC0IJyP7przLI/4G3AooUowFQfVqsJffnAJhRBKZ2NJsvsANK4XdsrvH9Pd+FTMsicc1YEeiDr3qHWAWwGdCLRSooTvjOkmDohUCGY2WxKN4r3UgzE1ZQcD4tP07Re8RPhCTC37daQeaTDzNKSSXU9LpoItknSAgQ8oK+9c6QPHLYitJNtBTM/C+4Rm4oTfkB9v+oTGiFIGrPozT13JAH1D64yfUTFPw32m7SyRGTgQDCvV+iv+e5VFAYgbxWY1rcwbab2PH9BBvowQsmd/LSxKWtX7f38Lr9s88dGI/OZ5zFr7r1ofvtmksWPkLeUdGNeYc7py7U2HttYV2MZdCab2/VKC/xhHs0E8du6FEuXflWJqpvjZjaN80R2UthtNpxgSQjcgitUrXUAUHnqhldGcGzuoGw9WIsuvRPP83TDRW3zu05QgrrpbzudlSXCDM683DhqeTTp70Ocz2+0XrpK3Oppq8g9O+OsLStd1NmNdAKEUqmvvkgBLcVjwGdgZAGyuoY0tVI0LVXdzVtgyZtWc/tzLltEom3nIhRQPTPvrb3+Y3Ov/1uFgg==
X-Microsoft-Antispam:
	BCL:0;ARA:14566002|51005399006|8060799015|12121999013|15080799012|23021999003|461199028|19110799012|5072599009|40105399003|440099028|3412199025|26104999006;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UGxYUjBuSjNmMEJwcEZmNitqOEw3MmprRlQ2V3FwZ2E1cDcvamlLTktyMUZD?=
 =?utf-8?B?TDdTY1YyYjRkQkdoNTVJM2VEM25NS3J3MEFFMzRoM1hYV3J5L3VSeUNGQ3JN?=
 =?utf-8?B?L0JpYUNHa2I1YStTNWR3N1JlNnp6T1RHQURFdlk1cFBzQmNLSmlKRWJTQUZH?=
 =?utf-8?B?N3JaN1hKcUZpdjRtWTR4dVhiRzdMQldDQ3ZTNEQ1TENONlAwOU9nblZlQkl5?=
 =?utf-8?B?Yll5L0M3WGx2aFVqdkE2SGZRZXYydTY5UGNob2Q1OEQza0RlTVA1TWNsck84?=
 =?utf-8?B?YWQwaXpOY3piTE1pelVrK1VweUpyaDNhVDl0TmRjYkp5aDNLWGZXQkNQL0hI?=
 =?utf-8?B?VmszMTY2ZmJCazR1TFVzd3JTaGNJL3N0cEtYZlpwOXZvcHlnM2E4dVdMQUZ1?=
 =?utf-8?B?cUpZVDVaSFFKVTVSN3k1UFVSYXNFR0lweEM5OGVHRFRLb0ZGYUpUc0oyOXB4?=
 =?utf-8?B?blcvR2c0ejQ1MWVSWFR0bktIQ1BWR1ZaY0xxT1pQSjNHMVZTcFgzakR2U3VP?=
 =?utf-8?B?ay8yUTFqME8wRFV5RnA0MEpuSWhPcVVMMlRxOWh0dVJLZlkxMTNsSGtqd2g1?=
 =?utf-8?B?ZjNxTU9TQ2dDZGtYdFQxNS83cEdaZlIrZEZqQk56aHRFT1A4MjF0bEpPL29P?=
 =?utf-8?B?RlNyaHVodWVxV294YzA3bzI2KzFkbnBVSnFtbDIrK2hleUZFUzlYZFAyZk8r?=
 =?utf-8?B?aXQ4bDI2bG01Y2NyaVNVb3EwSGtnL0x4eXp4QURYY3JYN3IwWFErWENXQzMy?=
 =?utf-8?B?OFQrN1NOYXpvL21wVUR0N2dEWFRQZlUrMzFNRkR0b1MzSzl3WXdIRUxOZXhy?=
 =?utf-8?B?T1dZS0RHU3dEdlFjZXE4dGl6Z1IwZU1oZnp6ckFyMkpYSStmMjd0TDM3MXhZ?=
 =?utf-8?B?cWNmVlJlcHVqelFpTXNBQjBsYy9Ic3lUMklKRHJOZjM3MDZ2RWtnTUtlVUtC?=
 =?utf-8?B?SGU2N3dwM242bVVORHQxc0ZLYnNBY0ZrVGlOREY1MTFCMGpSOTFDcWZwamVo?=
 =?utf-8?B?bVI1WnFFR3RxZ1JOUUdPQnFsY29JZ2treXljS2pvV3dYVFM1U0tGVS9lenZv?=
 =?utf-8?B?eVFvb1MxL2xXdkZYazdiTXRxRFAzU3F5WnkzZTArZGdPYlBZVFB0TlJOMTNt?=
 =?utf-8?B?Q3EyYTltUDhLaWxBcnJJKzhVYzRvT3c5NXNSRGZWMitQanhabU1QSmcybHFm?=
 =?utf-8?B?T1pkWEZ5Z0VEeFpOYlVFYTNoQkxiS0M3bFQ4cjJYbjJsbVlEcnBZaFpiY0lx?=
 =?utf-8?B?dThRZStjeXNPQnlJckhIK2xnWjF6eGJtT0hGN2M0TmI0L1JaUHpkS1E5UVpt?=
 =?utf-8?B?dEp0TkFyNFkybGtWQkFjQkdxWmluOWd3dGpJVjVKYzlGSXJXVmJEK0dYNXVF?=
 =?utf-8?B?UUVrcS9sR1MvaERVb1pPSWlVcTVHTmZpeGM2ZnlzU3lLcFhpZlViS3ZyeUgv?=
 =?utf-8?B?L0djVGZ1UXB0cTFDb015cWQyNWVYaGljUEh1Z2JCVFhDbmFmVkdiRHZ5VXNB?=
 =?utf-8?B?a1MxS0RkMXFoQjM2VkpzS2RZYmJIcGQ1NHdzOWY5YTR2VTAxTE8xSXZsQVBk?=
 =?utf-8?B?UjJUY1FqZ3Q3TTlJQ1VacjYwaThnYUw0cmgwNnlSeFJJVzhkK1N5QytuVUp4?=
 =?utf-8?B?Y05MNWhyT1cvUlJWWGU3cHJzamRvbVgwb3AwQk9iWFQrVGhKdG5oTGJFVk80?=
 =?utf-8?Q?vbfb/YQ4211oOPsB5M+K?=
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ejZpbG42ckNYa2dBU05CUTNKL0lhUmNmRTRoTUFnc2M5UWpQdkhUdlZVRHB3?=
 =?utf-8?B?ZGliTUd2TURGay9jMDVuWHh1dllBakFuZlQ1Ym5QZUZHRnNoYmlxNHRnSEcy?=
 =?utf-8?B?bU5JYUloTmxVc2JqOFFPN0lyMnUwQVZGNHVIR3V0RytEMDM5ZitjR2loWG1Z?=
 =?utf-8?B?US9TSk01Nk92azNmK2lrMWsxSk5lcU9yb0FiY0FMT2U1d0ZuOUs5QTYrSjZ4?=
 =?utf-8?B?TkxweWJqdXUrS0hzajBtcmk2dzBkUnBGb1c2c3hUdENKbm51YlBkdXJscndt?=
 =?utf-8?B?eTB2cHpWYXFsa2k0VmpVSFJPNysyVjBEdUFHeWZGRE9WREJCZTFya213Sjk3?=
 =?utf-8?B?SjJuK3k1VFJjNHhVaXRHUk1EMFVIRVZRR2FZV0c4NFB0R2RqTXU4YkFPMnNm?=
 =?utf-8?B?VElSRjNjZWNIbUhTQ01WUDJCS0cvcmp5Y1VjMVVDck1DMzJ0VlBEV3NWT1FQ?=
 =?utf-8?B?R3V4QXh6bkhTWUV3ZWtqMmE1RCtpM2FyUDlTZTQvUVhhZnlob29vemQxTTRp?=
 =?utf-8?B?Zm5SVG1KamlBSTdRc0Q0SThoTEJzVDE2YkVVUzBxcnAzTFRNdFVmWE1vcm42?=
 =?utf-8?B?K0JDNjZhZFF2TlpvTkMvZEZ4ZS9ZVVZCRmg1UDA0Y1Vod3JCT1dtM1JXcVkz?=
 =?utf-8?B?YUMvcG5qN1lCbTVkS1hGWkZtOG5KQ25GK0t1TFRXV0dXVURqZzdrVHI3eWFp?=
 =?utf-8?B?YTltdlo3UVQ5ZVo1L1MyRUYrWlBZRjlSVG1CUU9Xbks0U01zcnpKT3lVczhS?=
 =?utf-8?B?QUNEOVk5VXNlZ1hmUFBxbjBWdklya1o2RnF3WWo5YWdEVGp2RWxFbDFhSGJY?=
 =?utf-8?B?ZlZyRG5jVzYwYkFBcisvMng0YzI5TkZuQUhWK2M4WmEzQWJsUUwrb2JvZnow?=
 =?utf-8?B?Y3U2ZFVuZ3RKaHA4YVc3bmJhMXMwUitoVnNCUFN2Vnl0MWQ5SzluRWRHZEpQ?=
 =?utf-8?B?NW5BejM2aG0xUmZVYTc3K3Q1S2pzR25mSVJGcGJJWVZIZnRYbExlZVRqQXMr?=
 =?utf-8?B?U3dnY0RLalBTYm91VzREQTMxaFVhRkRBVlFZWFpocU50dDlJMzIvNlZ3UG10?=
 =?utf-8?B?eG5WcDlKNVBYQ2dLcm1oSUpzYUlLZitaS2dMNTBYUXpjNkZaQ0hvYTMrMUtP?=
 =?utf-8?B?NFU2bHlKMVZycVNqa0FaSmNrUWFVNCtOME02a3ljNG5qVXJMQ2ZteS9NdWZ5?=
 =?utf-8?B?UnU1alNHUG5TRC9NVDVVMFhIOXAzbWV6VlNPc1I1N3hVakZQT2EveUY4clBO?=
 =?utf-8?B?OEgzMllhWHJNWUJlZzBhay9ha016bVZ3ZG9PQkNDejRCQjFEZnk3M0V0TlhV?=
 =?utf-8?B?dlN2bnN5MHJpeXprNkRRRnZHd2h0SUtxZE45S3oyR2NBSTBBalAzRDBQTnQ1?=
 =?utf-8?B?djJHZ1hkdW1FMGQ2aVd6L01HbzJVL2pTeTNLUDVSZHFTcXpSSTlXelNSWHY2?=
 =?utf-8?B?aGo2bFhIZjl1dVpMQTR4ZTJhcS8rSTJDbVUxdFRnK1JMVmlpZTc2MjdhdDNo?=
 =?utf-8?B?N0ZLMkxHaXhVVXB5L2ZGRjFZTm1ic3NLaFVSZ3NEZnFYa1pjR1IwYmNlVWNU?=
 =?utf-8?B?cTVKb1BuUkN6Rm1Ocm1KTWdrL0tkTVFMdGRUT0phbjFJRzN4MXVTTHpQWUcz?=
 =?utf-8?B?cHNsdVcvZXJ0ZU1PcGE4Y0ZoeXpkd0NkNDVMdGRucGhDTVE4eGY1VzBvZmxF?=
 =?utf-8?B?c1FoTzE1bitKY3JVcGFuRENES0ZoMWZ3OWVldDNmZnF4Zm16aWtDVzdDWitQ?=
 =?utf-8?B?NmcwNFFOTDY4Q0hrQzdib21mZG80b2VVSlJaN1ZldE9VZDVvN3VZYXIyVE1n?=
 =?utf-8?B?eEhBNk91SFl6RmRtZUtjYTdkaEpneEl3N2ZPdnRSejBrUzJuL2Rld29uU2Jm?=
 =?utf-8?B?eWxsZnpiNm5aNERTSXNTak91WnJtRjZNVXdSVEFOSXRDTlBWbTFZRytYV2ha?=
 =?utf-8?Q?I7mZtu13VEe2NnRCoXwoG3GFsJsyEuij?=
X-OriginatorOrg: sct-15-20-9412-4-msonline-outlook-eee9a.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 3cf889cd-17f5-4d5b-1275-08de607c8cee
X-MS-Exchange-CrossTenant-AuthSource: AM8P250MB0170.EURP250.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2026 03:55:19.5388
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4P250MB0831
From: bobwei9@hotmail.com (Bob Weinand)

--------------fo0XxMb447gVEPvAfp3u9gyU
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hey Marco,

On 27.1.2026 13:45:06, Marco Pivetta wrote:
> Hey Tim,
>
> I went for "abstain".
>
> I'm a proponent of functional programming paradigms, and I frequently 
> touch Haskell / Nix, which have `let ... in ...` and `... where ...` , 
> which are nice.
>
> I feel like cluttering the PHP language for something that is already 
> (in my own opinion) resolved by IIFEs (and inlining/optimization 
> thereof) is not necessary.
>
> I don't mind if the feature makes it into the language, but I feel 
> like it just complicates the AST further, for very marginal gains.
>
> Greets,
>
> Marco Pivetta


That's pretty much the sentiment I share. It's additional complexity for 
the language, with a benefit not worth it.

I definitely prefer this over context managers (though they don't solve 
exactly the same goals, there's quite a bit of overlap).

But for me I'd like to see neither.


As to the more specific semantics of the RFC:

It's not natural to write code this way (especially if there are 
multiple such objects created across a function - you don't want to nest 
5 times, for 5 objects), and there are only very few instances where it 
actually matters when exactly a value is destroyed.

While the examples certainly correctly show usages where it's useful, an 
explicit unset(); just solves this as well in most cases. However a 
let() is much more implicit than the actual unset() telling me "I NEED 
this to be cleared here". It also doesn't prevent me from outliving the 
value.
It feels like let is supposed to be clearing the object. However, with 
your example for process_file() it's fine. However if you have 
zend.exception_ignore_args=0 (as you should if you disable displaying 
errors) and forward the $file object as an arg (e.g. read_all($file)), 
the $file object will be attached to the exception (being an arg). It 
will not, as one may expect, be actually freed when the exception is thrown.
That's subtle, and let() isn't the holy grail for solving these things. 
It creates false expectations in sufficiently complex code.


The main remaining utility I see in let() is highlighting intentions, 
rather than being actually useful in the language. Which goes back to 
the first point of "additional complexity, but not worth it".


Thanks,

Bob

--------------fo0XxMb447gVEPvAfp3u9gyU
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Hey Marco,</p>
    <div class="moz-cite-prefix">On 27.1.2026 13:45:06, Marco Pivetta
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CADyq6sJonm8o4+BFph2zJO=oeAJpQXMRmOhnJpixRoq2UC2Y2g@mail.gmail.com">
      
      <div dir="ltr">
        <div>Hey Tim,</div>
        <div><br>
        </div>
        <div>I went for &quot;abstain&quot;.</div>
        <div><br>
        </div>
        <div>I'm a proponent of functional programming paradigms, and I
          frequently touch Haskell / Nix, which have `let ... in ...`
          and `... where ...` , which are nice.</div>
        <div><br>
        </div>
        <div>I feel like cluttering the PHP language for something that
          is already (in my own opinion) resolved by IIFEs (and
          inlining/optimization thereof) is not necessary.</div>
        <div><br>
        </div>
        <div>I don't mind if the feature makes it into the language, but
          I feel like it just complicates the AST further, for very
          marginal gains.</div>
        <div><br>
        </div>
        <div>Greets,</div>
        <div><br>
        </div>
        <div>
          <div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">
            <div dir="ltr">Marco Pivetta&nbsp;<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>That's pretty much the sentiment I share. It's additional
      complexity for the language, with a benefit not worth it.</p>
    <p>I definitely prefer this over context managers (though they don't
      solve exactly the same goals, there's quite a bit of overlap).</p>
    <p>But for me I'd like to see neither.</p>
    <p><br>
    </p>
    <p>As to the more specific semantics of the RFC:</p>
    <p>It's not natural to write code this way (especially if there are
      multiple such objects created across a function - you don't want
      to nest 5 times, for 5 objects), and there are only very few
      instances where it actually matters when exactly a value is
      destroyed.</p>
    <p>While the examples certainly correctly show usages where it's
      useful, an explicit unset(); just solves this as well in most
      cases. However a let() is much more implicit than the actual
      unset() telling me &quot;I NEED this to be cleared here&quot;. It also
      doesn't prevent me from outliving the value.<br>
      It feels like let is supposed to be clearing the object. However,
      with your example for process_file() it's fine. However if you
      have zend.exception_ignore_args=0 (as you should if you disable
      displaying errors) and forward the $file object as an arg (e.g.
      read_all($file)), the $file object will be attached to the
      exception (being an arg). It will not, as one may expect, be
      actually freed when the exception is thrown.<br>
      That's subtle, and let() isn't the holy grail for solving these
      things. It creates false expectations in sufficiently complex
      code.</p>
    <p><br>
    </p>
    <p>The main remaining utility I see in let() is highlighting
      intentions, rather than being actually useful in the language.
      Which goes back to the first point of &quot;additional complexity, but
      not worth it&quot;.</p>
    <p><br>
    </p>
    <p>Thanks,</p>
    <p>Bob</p>
  </body>
</html>

--------------fo0XxMb447gVEPvAfp3u9gyU--