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 PM 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, like this:
> >
> > public function f(string $key) {
> > return $this->cache[$key] ??= {
> > // 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 = expr {return 5;};`.
For the return syntax, let's simply use `return`, instead of a new
language construct like "<=".
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 === expr {});
assert(NULL === expr {return;});
assert(NULL === 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 = match ($x) {
1 => expr {}, // IDE complains, but PHP does not care.
}
$fn = fn () => expr {}; // Totally ok.
$fn = fn (): array => expr {}; // Error at runtime when it is executed.
$fn = fn (bool $arg): array => 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 = expr: array {return [];};
We can also use generators:
$generator = 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 ??=.
These exist a lot within Drupal, both with runtime cache and persistent cache.
With the expression block these could be shortened like this:
$x = $runtime_cache['x']
??= $persistent_cache['x']
??= {
... // Calculate value for x.
return $value;
};
I could also see it used in generated code that behaves as a huge
nested expression.
