Re: RFC: Support for multi-line arrow functions
| From: | Marco Pivetta | Date: | Sat, 03 Oct 2020 21:39:32 +0000 |
| Subject: | Re: RFC: Support for multi-line arrow functions | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-111992@lists.php.net to get a copy of this message | ||
Hey Nuno,
<http://ocramius.github.com/>
On Sat, Oct 3, 2020 at 11:09 PM Nuno Maduro <enunomaduro@gmail.com> wrote:
> Hey internals,
>
>
> 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.
>
>
> As you may already know, PHP 7.4 has introduced one-liner arrow functions
> (aka short closures). Now, this pull request adds the possibility of those
> arrow functions to be multi-line. Just like in Javascript, or Hack. Let's
> see an example:
>
>
> ```php
>
> $users = [/** */];
>
> $guestsIds = [/** */];
>
> $repository = /** */;
>
>
> $guests = array_filter($users, fn ($user) => {
>
> $guest = $repository->findByUserId($user->id);
>
>
> return $guest !== null && in_array($guest->id, $guestsIds);
>
> });
>
> ```
>
>
> In short, the advantages are:
>
> ```
>
> $values = array_filter($values, function ($value) use ($first, $second,
> $third) {
>
> // vs
>
> $values = array_filter($values, fn ($value) => {
>
> ```
>
>
> - Multi-line arrow functions don't require the
use keyword
> to be able to
> access data from the outer scope.
>
> - Also, in some cases, fn (/** */) => { is just shorter and
> simpler than
> function (/** */) use (/** */) {.
>
>
> This pull request has been very well received by the community on Github,
> and also on Twitter:
> https://twitter.com/enunomaduro/status/1311572174256340992.
>
>
> So, I am writing this email to get your feedback about having this feature
> in the core of PHP. Note that, if eventually, you think it is a good idea
> to create an RFC on this, I will need to get some RFC karma - my wiki
> account is nunomaduro.
>
Overall, seems like unnecessary added syntax for something that already
works just fine.
Pros:
* unclear
Cons:
* more scope leak
* +1 way to do what we already do just fine
* more lexer/ast complexity for downstream projects
If you want to make an RFC about it, it really needs a compelling "pros"
section, because there aren't any, so far :-\
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/