Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120661
MIME-Version: 1.0
References: <CAB-BujbxK5i31K+FgeKL+nSLFNFfELxz6UPbNmMnUrKkM49qow@mail.gmail.com>
 <CAPyj-LB7cb=yVvf-ZuHpHdtsDim9L0gtWPkh-oMzN1_kXyJ1wQ@mail.gmail.com>
In-Reply-To: <CAPyj-LB7cb=yVvf-ZuHpHdtsDim9L0gtWPkh-oMzN1_kXyJ1wQ@mail.gmail.com>
Date: Thu, 22 Jun 2023 14:35:08 +0200
Message-ID: <CAB-BujbtCNh0bRMjWqQBaMzuYVjac24tsJ35mEeiGPb1deZo5A@mail.gmail.com>
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: 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: andreas@dqxtech.net (Andreas Hennings)

Hello Ilija,

On Sat, 17 Jun 2023 at 13:27, Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
>
> Hi Andreas
>
> On Fri, Jun 16, 2023 at 9:23=E2=80=AFPM Andreas Hennings <andreas@dqxtech=
.net> 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, l=
ike 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 looked at this and I think all of this can be solved.

About ambiguity with existing code blocks:
I think we should prepend a new keyword like "expr".
I was a bit hesitant to introduce a new keyword, but I think it is the
cleanest solution.
So it becomes `$x =3D expr {return 5;};`.

For the return syntax, let's simply use `return`, instead of a new
language construct like "<=3D".

About return being required or not:
Let's do the same as in a regular function body:
- If return value is omitted, an implicit NULL is returned.
- IDEs / static analysis can look at the wider context and complain if
it thinks a return value should be added or omitted. PHP can simply
ignore the problem.

This means that the following will be true:
assert(NULL =3D=3D=3D expr {});
assert(NULL =3D=3D=3D expr {return;});
assert(NULL =3D=3D=3D expr {return NULL;});


>
> I believe it would be best to address blocks for match arms and arrow
> functions separately.

The new syntax could be used in all 3 cases:

$y =3D match ($x) {
  1 =3D> expr {},  // IDE complains, but PHP does not care.
}

$fn =3D fn () =3D> expr {};  // Totally ok.
$fn =3D fn (): array =3D> expr {}; // Error at runtime when it is executed.
$fn =3D fn (bool $arg): array =3D> expr {if ($arg) return [];};  //
Possible error at runtime when it is executed.

We could also declare a return type on the expr, like so:
But I don't see a big advantage.

$x =3D expr: array {return [];};


We can also use generators:

$generator =3D expr {yield 'A'; yield 'B';};
assert($generator instanceof \Generator);


>
> I don't believe blocks for general expressions are that useful in PHP
> due to the lack of block scoping.

We could introduce block scoping for that specific language feature.
And even without it, to me these expression blocks would still be useful.

If the default is "use all by ref, leak all", it would feel more like
other language constructs like foreach(), if/else etc.
If the default is "capture all by value", it would feel more like a
short closure.

Perhaps there could be something to control the capturing type.
E.g. a `use` part?
expr {..}  // Capture all by value, don't leak inner variables.
expr use () {..}  // Capture nothing.
expr use ($x) {..}  // Capture specific variable $x, by value.
expr use (*) {..}  // Capture all by value, don't leak.
expr use (&*) {..}  // Capture all by reference, leak all?

Or we could have different keywords:

expr {..} // Capture all by reference, leak all inner variables.
scope {..} // Capture all by value, don't leak.


I personally think mostly of uses cases with cache and ??=3D.
These exist a lot within Drupal, both with runtime cache and persistent cac=
he.
With the expression block these could be shortened like this:

$x =3D $runtime_cache['x']
  ??=3D $persistent_cache['x']
  ??=3D {
    ... // Calculate value for x.
    return $value;
  };

I could also see it used in generated code that behaves as a huge
nested expression.



> 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-ran=
ge-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 =
arms.
>
> Ilija
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>