Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120659
MIME-Version: 1.0
References: <CAB-BujbxK5i31K+FgeKL+nSLFNFfELxz6UPbNmMnUrKkM49qow@mail.gmail.com>
 <CAPyj-LB7cb=yVvf-ZuHpHdtsDim9L0gtWPkh-oMzN1_kXyJ1wQ@mail.gmail.com> <af803262-d140-9a16-1f3a-5a761338de83@gmail.com>
In-Reply-To: <af803262-d140-9a16-1f3a-5a761338de83@gmail.com>
Date: Thu, 22 Jun 2023 13:50:29 +0200
Message-ID: <CAB-BujYPqjzUxhtYpwuWC+rJP1V43Qyt0yhS6=Ezvb2DDK94XQ@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Expression code blocks
From: andreas@dqxtech.net (Andreas Hennings)

Hello Rowan, Ilja,
(sorry I did not see these replies sooner, I do some forwarding but it failed)

On Sat, 17 Jun 2023 at 16:59, Rowan Tommins <rowan.collins@gmail.com> wrote:
>
> On 17/06/2023 12:26, Ilija Tovilo wrote:
> > I don't believe blocks for general expressions are that useful in PHP
> > due to the lack of block scoping. Your suggestion to make the block a
> > separate closure could avoid that (as well as the optimizer issue
> > mentioned below) but comes with new issues, like making modification
> > of captured values impossible without by-ref capturing.
>
>
> I've been pondering various things in this space for a while,
> particularly since the last auto-capture closures RFC. I haven't quite
> coalesced on a coherent concept, but there are a few things that I think
> inter-relate:
>
> * Opting into block-scoped variables, while retaining full access to the
> outer scope, like JS "let"
> * Code blocks as some kind of first-class thing, distinct from closures

I think this would be my preferred option.
We would have to discuss how variables are scoped and captured, but I
could myself being happy with different options.

Currently variables from outside in short closures are auto-captured
by value, and nothing leaks outside:
https://3v4l.org/mdJvM
I would be happy if it works the same for expression code blocks.