As you mentioned the => syntax is already being used in PHP with associative arrays and can conflict in some places. Taking your example [$x => $x*2] this creates an array with $x doubled on index $x, while a user might want to create an array of functions.

The fn() syntax was a non-conflicting alternative, which got most support for being not too weird.

I wonder why they didn't use `==>`, which PHP alternatives like Hack[1] already use.

[1] https://docs.hhvm.com/hack/functions/anonymous-functions

In the end it's a matter of taste and preference. There are other options as well. Each contributor (and user) certainly has a favorite and in the end it is the solutions with biggest support (and least objection)

Bike shedding can certainly be done infinitely and sometimes one has to make a choice and move on.

(I have been release manager of PHP in earlier times and helped to steer through the namespace seperator debate and did the decision to not do short array syntax, yet, but wasn't involved in the short function syntax debate)

Mixing named parameters with unnamed ones is ripe for confusion. The syntax is also going to get rather ugly now that parameters can be typed, too. If I need to pass around more than 3-4 parameters and their names/types matter a lot, I think I'll just define a class with clearly named properties and pass around an instance of it.

I'd love to have a shorter object syntax, too. For the time being, I'll make do with

    $city = (object)['name' => 'Berlin', 'population' => 3748000];

which is a little verbose but gets the job done.

I think there is an rfc for object initialization similar to C#:

    $city = new City {name: 'Berlin, population: 374800};

Edit: found it (and it uses = instead of :) https://wiki.php.net/rfc/object-initializer

TypeScript spoiled me. I want PHP to have generics and all the type-system goodness that TS brings.

That would be great. I would also love it if TS supported runtime checks like PHP.

My thesis was working on top of ConcreteTypeScript, which supports runtime checks https://github.com/ludamad/LocusTypeScript. My contribution was adding the ability to define types inline with code, and check those using tagging. That being said, it's all very experimental.

I’ve wanted named parameters for years! There was an attempt about 6 years ago but it went nowhere.

https://www.reddit.com/r/PHP/comments/50xcmi/what_happened_t...

Because there are several contexts where $x => $x is already valid PHP to mean something entirely different (array, foreach, ...).

would like if they'd just change the syntax to foreach(something as k,v) or $arr = ['something':'value']... or then could use => ...or they could just use -> and change -> to . notation.. I use js a lot more lately so having it closer resemble es6 would make jumping back and forth easier.. I often start writing a json object when I want an associative array.

... change three different operators because you can’t handle the syntax of two different languages? Sure why not.

Perhaps php should also drop all type information so it can be more like the cluster fuck that is “modern” JavaScript too? Maybe change “const” so the constants it declares aren’t... constant?

> I wonder why they added the "fn()" thing on the left of the array functions.

There would be ambiguity without it: https://wiki.php.net/rfc/arrow_functions_v2#syntax

But does it have to be =>? How about ~>?

    $a=[$x ~> $x*2, $x ~> $x*$x];
    $a[1](5); // 25

Looks cool to me.

~ is annoying to type on some keyboard layouts (Alt Gr and + onna German keyboard)

Also PHP tries to be "googlable". Typing "fn PHP" into Google should bring relevant hits, for people never seen such a construct.

> Also PHP tries to be "googlable".

If not insisting on the "google" part, there always is http://symbolhound.com/?q=php+%7E%3E

I noticed lately google is starting to understand symbols in certain contexts. Searching "php =>" actually does provide relevant results.

There's some rationale here[0]. Basically they'd need to use a parser that on ambiguities would have to go down all possible routes concurrently until all but one fail, which can lead to performance costs. Using a prefix keeps things simple.

[0] https://wiki.php.net/rfc/arrow_functions_v2#x_x_y1

To prevent ambiguity at parser level. To prevent collision with array definition.