Short Closures 2.0

Read the RFC
98
368 yes
65 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%
1

Would love to have the elegance of short closures in PHP 🙏

Share:
Laravel driesvints avatar
driesvints
voted yes
1

Being possible to create closures that share the scope would be a game changer because it would mean less work and headaches with the use() block that in some cases if you don't pay attention it could lead to a lot of time waste on refactors and maintenance in code.

I think that with this, we would be able to write cleaner code that's easier to understand!

Share:
wendell_adriel avatar
wendell_adriel
voted yes
1

As many have already said, this is a common feature in other languages. As it stands, PHP has a half-baked version of short closures since introducing arrow functions. This is the natural next step.

Share:
Laravel jbrooksuk avatar
jbrooksuk
voted yes
1

It would be far more convenient, especially when code that starts as a short closure needs to do more, which is often the case, temporarily, when debugging. It will also help developers coming to PHP from other languages. I don't often find value from use () scoping either, but we'll still have the option when needed.

Share:
jessarcher avatar
jessarcher
voted yes
1

It improves the readability and usability of closures

Share:
jeidison avatar
jeidison
voted yes
1

Arrow functions in PHP were an awesome addition and I would not work without it today. I wish we had the multi-line version.

Share:
jcambien avatar
jcambien
voted yes
1

Another (extended) syntax for anonymous functions. We do not need to apply closures on everything.

Share:
dsentker avatar
dsentker
voted no
1

its modern

Share:
meshackjr avatar
meshackjr
voted yes
1

This definitely makes life easier. I find myself writing a lot of anonymous functions for commands like array_map, array_filter and so on... and it really makes me sad when I realise I need to have a multi-line function body and need to get back to the default function syntax. It's a simple yet very useful feature PHP could have. Actually, I don't mind keep using the syntax like fn() => as far as it supports a multi-line body and bypasses the need for the use(...$vars) command which is also kind of annoying.

Share:
jhonatanjacinto avatar
jhonatanjacinto
voted yes
1

Short closure is a trendy syntactic-feature in many languages this days. It's easier to write and read.

Share:
zbandhan avatar
zbandhan
voted yes
1

I love this proposal. It basically makes closures up to date with other programming languages, and is sorely needed in my opinion.

Share:
thomasalrek avatar
thomasalrek
voted yes
1

as often, it's more for a question of readability that I vote "no"....I prefer by far a good code more readable than shortcut solutions

Share:
grazulex avatar
grazulex
voted no
1

I don't usually like syntactic sugar added to the PHP, but this RFC is useful. I totally see use cases for this in my projects because I use short closures all the time.

Share:
Contributor serhii avatar
serhii
voted yes
1

Supporting the RFC aligns with the direction modern programming languages are taking. In my work with PHP, I've often found closures to become needlessly verbose, especially when multiple variables are involved. The requirement of the "use" statement can make the code bloated:

return Cache::remember('key', 60, function () use ($start, $end, $other) {
    // Logic here
    return $result;
});

Multi-line short closures would eliminate this redundancy, making the code more concise and readable. On a side note, while the "fn" keyword isn't the core issue, it further adds to the awkwardness. As PHP continues to evolve, it should prioritize developer experience, and this RFC pushes it in the right direction.

Share:
rihardsgrislis avatar
rihardsgrislis
voted yes
1

use look like deprecate syntax

Share:
stolentine avatar
stolentine
voted yes
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!