Short Closures 2.0

Read the RFC
101
373 yes
66 no

This RFC proposes a way to have multi-line short closures — closures that don't need explicit use statements, but can still have multiple lines and a return statement.

Click the bar to cast your vote!
85%
15%
121

At least once a week, I throw away an array_map because it ended up looking too bloated and go with a classic foreach instead. Short Closures 2.0 without the use(...) block would've solved this problem, just 2 votes...

Share:
davi avatar
davi
voted yes
81

We spend a lot more time reading code than writing it. The elegance of short closure combined with the convenience of variable scope usage has already shown to be a game changer on Typescript and there doesn’t seem to be any technical issue with having it on PHP.

Share:
marco avatar
marco
voted yes
39

PHP is evolving. There are new concepts added to many programming languages to ease writing and reading (more important!). PHP should focus more on developer experience (but not for legacy projects that get never upgraded to PHP 8+).

Share:
eugen avatar
eugen
voted yes
24

The 'use' statement clarifies the scope for me. So a proposal like this could have the side effect of mixing scope which would lead to a confusing code.

Share:
nabeel avatar
nabeel
voted no
13

I really do not want to see this in PHP because it tempts to apply closures on everything. The question is not if we can but if we should.

Share:
marko avatar
marko
voted no
12

It improves the readability and usability of closures that consist of more than one assignment.

Share:
alexander avatar
alexander
voted yes
10

Makes code more clean because it is shorter and the use keyword is not needed anymore.

Share:
buismaarten avatar
buismaarten
voted yes
8

mmh, seems to me that just replacing function by fn and having such a different behaviour is risky

Share:
remivasco avatar
remivasco
voted no
8

Just look at how other languages solve this. C# for example. Make short closures like that.

Share:
ricardo avatar
ricardo
voted yes
7

Would avoid me having to use dodgy looking code such as fn($item) => [$this->doSomething($item), $this->doSomethingElse($item)]

Share:
jw avatar
jw
voted yes
5

Auto capture by-value is clear enough with a single expression closure, but I think for multiple statement functions it could be confusing to have to keep track of scope. Being explicit (with use()) makes it simple and concise.

If this were to pass, I think the syntax should continue to include the arrow to signify the auto capture by-value intention. Just like in JavaScript, the arrow is used whether single expression or multiple, and the use of brackets is what separates them.

Share:
corey avatar
corey
voted no
4

Short closures were meant to be that - short. If you need multiple lines, just create a function (it can even be a closure). Or just use a standard anonymous function instead of a short closure. It will also create confusion with having access to variables outside the short closure scope while letting it look like a normal function.

Share:
jim avatar
jim
voted no
4

Since we have already autocaptures for one liners there should be also option for multiple liners.

Share:
raszekster avatar
raszekster
voted yes
4

I really love short closure. JS solve this

Share:
faisal avatar
faisal
voted yes
3

A breakthrough for language, easy to write easy to read.

Share:
Adrian avatar
Adrian
voted yes

Check out another RFCs

Property Hooks

A new way of interacting with properties

70
141 yes
90 no
Asymmetric Visibility v2

A new syntax for declaring the “set” operation visibility of an object property

21
21 yes
38 no
Interface Default Methods

Interface Default Methods improves backwards compatibility when changing interfaces, but also add a way to have multi-inheritance in PHP.

95
168 yes
264 no
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!