RFC: Support for multi-line arrow functions

If you want to make an RFC about it, it really needs a compelling "pros"
section, because there aren't any, so far :-\

I don't agree. There is one pro, and not a small one IMO if you use
closures a lot: skip use().

Since arrow functions have been introduced, I've several times naturally
tried to open braces, only to remember that it's not supported.
I love fn() for the fact that it doesn't require the use() statement, and
would love to see it extended to more than a simple expression.

— Benjamin

Hi Nuno,

A few days ago I opened a pull request that adds support for multi-line
arrow functions in PHP: https://github.com/php/php-src/pull/6246.

Welcome to the list. Firstly, it's probably worth having a look in the mailing list archives for prior discussions on this, as it was definitely discussed during the earlier short closures RFCs (the successful one that gave us fn()=>expr, and a couple of earlier attempts with different syntax and features).

Secondly, I'd like to point out that "short closures" actually have three fundamental features:

1. They have an implicit "return", making them ideal for single expressions rather than blocks of procedural code.
2. They automatically capture all variables in scope, rather than having to import them with "use".
3. They are shorter than normal closure declarations, both because of the above two features, and because "fn" is slightly shorter than "function".

I think it's worth making clear which of those three features we are hoping to retain by combining arrow functions with blocks.

Feature 1 doesn't extend to code blocks in an obvious way. In some languages, every statement is a valid expression, so you can place an implicit "return" before the last statement of a block. In PHP, that's not the case, so e.g. { $x = 'Hello World; echo $x; } cannot be converted to { $x = 'Hello World; return echo $x; }. Alternatives include converting to { $x = 'Hello World; echo $x; return null; } or requiring all closure blocks to end with a valid expression.

Feature 2 is probably the one most people actually want extended, but in my opinion is also the part most in need of justification, because it changes the language quite fundamentally.

There are currently very few places in PHP where the scope of a variable is not to the current function: properties of the current object must be accessed via $this, and class properties via self:: or similar; globals must be imported via a "global" statement, statics via a "static" statement, and closed-over values via the "use" keyword. (The main exception to this rule is the half-dozen built-in "superglobals"; I think there are a few more obscure cases.)

In a single-expression closure, as currently allowed, there is limited possibility for ambiguous scope. Extending this to function bodies of any size leads to much more risk of complexity and confusion.

If you want to capture variables $a, $b, and $c, but have local variables $x, $y, and $z, you would currently write this:

$f = function() use ($a, $b, $c) {
// $x, $y, $z must be local, because not imported
}

If we added an opt-in syntax for "capture everything", we might instead write this:

$f = function() use (*) {
$x = $y = $z = null;
}

Without re-initialising all local variables, we would no longer be able to know if they were actually local without looking at the surrounding scope for a value that might be captured. I am unconvinced by this trade-off of opt-out instead of opt-in.

One use case I've seen proposed is closures which capture a large number of variables; I would be interested to see an example where this is the case and is not a "code smell" in the same way as requiring a large number of parameters.

In the above example I deliberately did not use the "fn()=>" syntax, because I believe this is really orthogonal to the other features - my impression is that actual expression length (feature 3 above) is more of a pleasant side-effect than a top priority for most people.

I would personally prefer the "fn()=>" syntax to carry on meaning "this is an expression elevated to function status", and have some other syntax for a full closure that uses auto-capturing scope rules if that feature is indeed needed.

Good analysis.

I agree #2 is the strongest motivator for some kind of improvement / change.

In at least one prior language I have used there was no distinction between local scope inside and outside of a closure, so when I first realized I had to use the "use" clause to make variable visible it was surprising to me.

In PHP I find this requirement rather annoying in the majority of cases. My functions and closures tend to be short and the number of local variables I use — both inside and outside the closure —tend to be small so I don't have a problem with confusing scope. Having to explicitly name the variables in a use statement feels like unfortunate overkill. But I do get your point.

OTOH, when inherited local variables are NOT modified within the closure, does that actually cause a problem? (honest question)

If not — and please check my logic — I would suggest PHP 8.1+ could allow closures to IMPLICITLY inherit local variables, but ONLY for variables that are READ, not for variables that are written.

Given this approach, variables would still need to be declared when variables need to be written, e.g. "use ( &$foo )"

Although this relaxing of requirement to declare variables could theoretically break existing code, only code where variables are read inside closures before they are assigned with the same name as variables assigned outside the closure would "break", and those cases are flagged as a warning when error reporting is on.

For me, that would probably cover 90%+ of the use cases my the requirement to employ the "use" statement feels like overkill.

-Mike

If we added an opt-in syntax for "capture everything", we might
instead write this:

$f = function() use (*) {
     $x = $y = $z = null;
}

Without re-initialising all local variables, we would no longer be
able to know if they were actually local without looking at the
surrounding scope for a value that might be captured. I am unconvinced
by this trade-off of opt-out instead of opt-in.

One use case I've seen proposed is closures which capture a large
number of variables; I would be interested to see an example where
this is the case and is not a "code smell" in the same way as
requiring a large number of parameters.

Something like "use (*)" seems like a great enhancement to me. I often
use a wrapper function for SQL transactions, something like:

public function update(int $numberId, int $addressId, bool $isMainNumber
= false): void
{
     $this->transaction->run(function () use ($numberId, $addressId,
$isMainNumber): void {
       // Do all SQL queries for the update
     });
}

In these cases there is a lot of redundancy because of having to import
the variables, and if a variable is added, it has to be added in two
places in a slightly different way. The following would be much nicer:

public function update(int $numberId, int $addressId, bool $isMainNumber
= false): void
{
     $this->transaction->run(function () use (*): void {
       // Do all SQL queries for the update
     });
}

This would also increase code readability.

Actually there is a precedent in PHP where braces don't create a new
scope:
$a = 1;

 {
     $a++;
 }

 echo $a; // 2

This is true. Indeed, in general, scope in PHP is not to the nearest
pair of braces - if statements and loops don't create a new scope - but
it is, with very few exceptions, to the current function, with no
automatic inheritance/capture from the outer scope.

The fact that arrow functions don't have braces makes them look less
like a normal function, so it is less surprising that they capture from
their surrounding scope. The fact that they are limited to a single
expression also reinforces that they are intended for a specific use
case, and are not intended as a replacement for all anonymous functions.

Let's put it into context, here is how one of my service methods looks like:

 return $connection->transactional(function() use ($authorId,

$activityId, $parentId, $comment) {

... and this is not the largest one. Let's see how it would look like with
this proposal:

 return $connection->transactional(fn() => {

Just to be clear, the major gain here is not replacing the 10 characters
"function()" with the 7 characters "fn() =>", it is eliminating the list
of captured variables. So you would get equally clean code with a
"capture all" syntax, such as:

 return $connection->transactional(function() use(*) {

or Sara's suggestion from earlier today:

 return $connection->transactional(function() use($) {

If I've counted right, this takes your example from 46 characters down
to 17; but more importantly, that 17 is fixed no matter how many extra
variables you want to capture or how long you make their names.

And I'm not worried about scope leaking:
usually, the closure takes up most of my service method.

To me, this illustrates exactly why we should have an explicit
"auto-capture" syntax, rather than extending arrow functions: this is a
form you would use in specific situations where you know it's
appropriate, not a general-purpose replacement for the existing syntax.

As well as being shorter than the current syntax, arrow functions would
remind people of JavaScript, where it's considered best practice to use
arrow functions as much as possible, because they have better scoping

• in particular, they automatically bind "this", which PHP closures
  already do.

There are certainly use cases where automatic capture leads to more
elegant code than explicit capture; but there are also plenty of cases
where it makes code hard to follow, and leads to subtle bugs. That's why
I would like the two syntaxes to feel like equal options to choose between.

Regards,

--
Rowan Tommins (né Collins)
[IMSoP]