Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120609
MIME-Version: 1.0
References: <CAB-BujbxK5i31K+FgeKL+nSLFNFfELxz6UPbNmMnUrKkM49qow@mail.gmail.com>
In-Reply-To: <CAB-BujbxK5i31K+FgeKL+nSLFNFfELxz6UPbNmMnUrKkM49qow@mail.gmail.com>
Date: Sat, 17 Jun 2023 13:26:36 +0200
Message-ID: <CAPyj-LB7cb=yVvf-ZuHpHdtsDim9L0gtWPkh-oMzN1_kXyJ1wQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Expression code blocks
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Andreas

On Fri, Jun 16, 2023 at 9:23=E2=80=AFPM Andreas Hennings <andreas@dqxtech.n=
et> wrote:
>
> Hello list,
> I don't know if something like this was already proposed in the past,
> I did not find anything.
>
> Sometimes it would be nice to have a code block inside an expression, lik=
e this:
>
> public function f(string $key) {
>     return $this->cache[$key] ??=3D {
>         // Calculate a value for $key.
>         [...]
>         return $value;
>     }
> }

This has been discussed a few years back when match expressions were
proposed. I originally wanted to include support for code blocks along
with expressions to offer a more complete alternative to switch
statements. The other major use-case for block expressions are arrow
functions.

Unfortunately, a general solution seems suboptimal due to the subtle
semantic differences. See this message for my detailed thought
process.

https://externals.io/message/109941#109947

I believe it would be best to address blocks for match arms and arrow
functions separately.

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. It seems
confusing that fn {} is auto-executed while fn() {} isn't, as the
former looks like a shortened version of the latter. fn() =3D> fn {}
would also look quite weird. match ($x) { 1 =3D> fn {} } seems ok,
except for being somewhat lengthy.

On another note, the vote for blocks in short closures has failed
lately (https://wiki.php.net/rfc/auto-capture-closure).

The message above also addresses the syntax ambiguity you mentioned.
The {} syntax would be unambiguous in the most useful contexts (e.g.
function parameters, match arms, arrow function bodies, rhs of binary
operators, etc.). It is ambiguous in the general expression context
due to expression statements (statements containing a single
expression followed by `;`), where it's unclear (without lookahead)
whether the `{` refers to a statement block or a block expression.
Replacing all statement blocks with block expressions comes with the
added difficulty of allowing to omit the `;` of block expressions in a
expression statement.

I remember there also being issues with the optimizer (related to
https://www.npopov.com/2022/05/22/The-opcache-optimizer.html#liveness-range=
-calculation).
The details went over my head at the time.

I'm interested in picking this back up at some point, at least for match ar=
ms.

Ilija