Member since
It makes the code more readable, isn't one of the things we all strive for ?
Just use "fn" everywhere my fingers hurt from typing "uction" all the time.
Just add this and get rid of abstract classes and traits to make the language simpler, method conflicts resolution is not a big issue as it's already done in traits, also python, C#, Java, Kotlin all have a similar feature so I don't see what's the big deal with PHP as no developer will say that PHP is cleaner.
With First-class callable syntax available since 8.1, it would now be possible to write it as below, which is much better then string names of functions:
$result = "Hello World" |> htmlentities(...) |> str_split(...) |> fn($x) => array_map(strtoupper(...), $x) |> fn($x) => array_filter($x, fn($v) => $v != 'O');
For me, the most important argument is that the pipeline pattern is a tried and tested pattern, that this RFC builds upon. A couple of examples:
This RFC adds syntax to make using these kinds of pattern much more convenient.
On top of that, there's the argument that multiple modern languages support a pipe operator:
Finally, I've had numerous occasions where a pipe operator would simplify my own code — I have more than a handful real life cases where this would be useful.
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.
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...
I wrote down some thoughts on this RFC on my blog. I think it's worth rethinking our current definition of what "an interface" is. Especially since many languages are interface default methods as their way of multi-inheritance.