Member since
Even if you won't use this yourselve, it will allow libraries and frameworks to do some really cool stuff. LGTM!
Neat with first class callable syntax
Small but nice QoL improvement
Prevents having to add a trait to every class that has to implement an interface, being able to provide default implementations via interfaces would be a large DX improvment
I think complaints about the syntax being messy are really about the array manipulation functions being inherently hard to format nicely.
To be clear I agree that the proposed example isn't great, nested closures are never going to win any readabillity prizes. If however we look at any non-array based manipulation I think the readabillity is objectively better:
$name = 'my_user_name' |> fn (string $string): string => str_replace('_', ' ', $string) |> strtolower(...) |> ucwords(...) |> trim(...);
Or without first class callables:
$name = 'my_user_name' |> fn (string $string): string => str_replace('_', ' ', $string) |> fn (string $string): string => strtolower($string) |> fn (string $string): string => ucwords($string) |> fn (string $string): string => trim($string);
Bonus: this also adds runtime type checks to each step. Eg strreplace
returns string|array
I can't imagine anyone would think this is better:
$name = trim( ucwords( strtolower( str_replace('_', ' ', 'my_user_name') ) ) );
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');
I could have used it multiple times for array transformations. But the RFC still built on really ancient PHP behaviour (mapping functions as strings) and should be redone by fosucing only on modern syntax:
|> fn($x) => array_filter($x, fn($v) => $v != 'O')
|> str_split(...)
It will solve having to create traits to add a default implementation when creating interfaces and keeping it nicely together improving the DX
Creating traits for default implementation is just a pain. I want syntactic sugar
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.