> The pipe operator [...] syntax only works for unary functions, so higher arity functions must be wrapped in an arrow function.

It's coming - but to get PHP RFCs to pass they have to be salami-sliced, otherwise they're voted down.

https://wiki.php.net/rfc/partial_function_application_v2

The pipe operator makes it much easier to create home-grown cryptographic hash functions, as everybody used to do in the early 2000s:

    md5($password)
    |> sha1(...)
    |> sha1(...)
    |> md5(...)
    |> rot13(...)
    |> crc32(...)

Oh, now I'm convinced!

Many of the newer features have this problem. Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features.

Meanwhile it seemingly abandoned features and unique selling points, like the in-built templating, associative arrays with value semantics and the fact that it integrates well with C or the simple fact that it can be used to write web server scripts very easily. To me, many of these cool features have been largely ignored or even moved away from.

>Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features.

The problem is that the php project is maintained by (mostly) unsponsored contributors. There’s not a giant corporation behind it. Each of these new features are designed by a couple people (per rfc) and then discussed and voted by other contributors. The match keyword, for example, is consider as the future scope of this rfc which is still being worked on: https://wiki.php.net/rfc/pattern-matching

Also, a lot of these half baked features are designed to be implemented in steps because of what I said in my other paragraph and to increase the odds of being accepted (it’s well known that it’s hard to get an rfc accepted and a lot of good ones haven’t been able to pass the voting phase).

When you consider this, it’s amazing that we get so much from so little.

To be fair, PHP's internal development was once heavily sponsored by a corporation. That corporation's sponsored developer(s) were the primary source of resistance against BC breakage and forced the language to stagnate for years.

I don't understand how this is more bug prone. The nesting is a HUGE problem because it's extremely unreadable. The arrow is much more readable, and array functions are very simple too.

How many tubes does that appear in any codebase you've worked on? Those types of constructions are typically hidden away in "helper functions" that are straightforward to understand and debug. They are certainly not typical in business logic.

Now we have two syntax to be familiar with and maintain. And you just know the clowns are going to come along and convert one syntax to the other because they can, which completely ruins the git commit and you can't tell what actual functionally was changed at a glance. There will be bickering and bikeshedding about "modernizing" codebases.

I don't know, I think it's really fine. It's very typical to compose a bunch of array functions together and, honestly, I think that's good form most of the time. This makes that a little bit easier.

I'm sort of on the opposite side. I'm unconvinced by extra functions for arrays in the global namespace and I'm happier about syntactic improvements and debugging improvements.

I'm glad to hear a dissenting opinion. Interesting that we experience PHP differently.

What is your background? I've been working mostly with PHP and Python for about 25 years. Do you come from e.g. Java?