[RFC] Add ~> short from for Closure definition - #1254

In my opinion, the proposed syntax is rather less readable than the current closures syntax, but okay: 👍
It could be pretty good to use it for one-expression (sometimes also called lambda) function definitions.

What a brilliant feature! Please merge it into 7.0.

Well Hack/HHVM uses '==>', why doesnt PHP use the same operator then?

See RFC

I understand the fact that ==> may look more similar to array syntax =>, this is logical. But why is it better if PHP uses its own syntax? To me its better if PHP and Hack use the same syntax, and code will be easier to port between the two languages. Not mentioning, in PHP 8 or PHP 9, PHP and Hack may become one language.

It's really exciting that this feature is in the pipeline!

There is a little more cognitive load on the PHP/Hack community (considered as a whole) by having two syntaxes for the same feature.

The comment from @sgolemon is "Also, after much discussion, we'd probably prefer if PHP used its own syntax. Then we can keep ==> as we like it."

I'd like to know what possible differences could arise between Hack's and PHP's implementation of this feature that would necessitate that the syntaxes be different. My understanding is that they both desugar to a regular function (...) {...} with an automatic use (...), and since Hack and PHP already share the function (...) {...} syntax, the only wiggle room for additional incompatibility is the semantics of this desugaring, namely the variable binding rules. If the variable binding rules are the same, and simple enough that they are unlikely to change on either side, then I don't see why the same syntax shouldn't be shared.

==> is not confusing at all, everybody knows that => has only one = symbol.
~> looks weird and can be confused with -> (cognitive dissonance, kinda).

Did you consider --> and =>>?

~> is hardly legible on high resolution screens.

The symbol is more accentuated on monospaced fonts

What was the problem to create an RFC voting for both variants '==>' and '~>'? - cause now it seems that this good RFC will be burried among declined ones and we'll have to wait again for another proposal.

We'll have another proposal, by @morrisonlevi ;-) [based on this patch, just altered a bit]

But as we're not in hurry, just one proposal after the other.

Closing as the RFC was declined, at least for now.

R.I.P

Really this is more readable and logical:

function ($x) {
    return $x * 2;
}

And very standard in programming languages. And besides "~" is used in github markup.

We're looking forward to being accepted in PHP 8 as an improved version...

I like short syntax (like arrow functions in ECMA) x => x * 2 instead function(x) { return x * 2; }

@kakserpom Did you consider --> and =>> if ($x-->2) ex.

Please add short Closure feature,from long time waiting...

var multiply_result = (x, y) => x*y; // IN ES6

$multiply_result = (x, y) <= x*y; // IN My PHP

$multiply_result = (x, y) <> x*y; // IN My PHP

$multiply_result = (x, y) <=> x*y; // IN My PHP

// Why already have <=> it is not that much readable.

it could be more python-styled like

$result = lambda $x : $x*2;

Better idea in the title of this pull request. Short syntax, too few chars... "~>" is better variant. Like JS, C#, but in one's own way.
I need for it. It so confortably.
PHP syntax looks like JS, ES, TS, C#, C++, Java and are not equals to Python, so idea told by @anon767 is not good. But many peope wants this feature. Please add it. Thx.

@DAVIDhaker Yes, I'm really confused and I don't understand why the original $x ~> y idea rejected. There is a new proposal that indicates fn($x) => $y but I prefer the original.

Better use default -> like in Kotlin, or => in JS.
It should be more standart operator. ~> looks like php want to be uniq.

-> and => are not possible because they would be ambiguous.

For =>:

[
    $foo => $bar,
]

Does it defines an array with an item with key $foo and value $bar or an array with a short closure $foo => $bar

For ->:

$foo->$bar

Does it defines a short closure that takes $foo as argument and alway return $bar or are you trying to access the property of object $foo whose name is stored in the variable $bar.

=> is actually the standard, but not suitable for PHP. Also fn prefix looks verbose. So I prefer ~> rather than the others.

I dont know why you write that => is not suitable for PHP. There are no collisions with arrays: lambdas { => } and arrays [ => ].

Code sample for example:

from($elements)
    ->filter({ $it => $it->isEnabled })
    ->map({ $a, $b =>
        echo 'Some side effects';
        return $a + $b;
    })
    ->sort({ $l, $r => $l < $r })
    ->forEach({ $it => print($it) })

Additional suggestion: in one line statement ';' and 'return' is not required.
As you can see, this syntax is very close to Java, Kotlin, Swift lambdas syntax.

Why not just use parentheses to solve the issues mentioned here, as suggested by @ssipos90?

Array value

[
    // key/val
    ($x) => $x * 2,

    // func val
    (($x) => $x * 2),

    // key/func
    ($x) => ($x) => $x * 2 // parens around func optional, only required for non-keyed values
]

Yield

// yield key/val
yield ($x) => $x * 2;

// yield func
yield (($x) => $x * 2);

Then you can use braces for multi-statement function bodies, as in other languages.

This is not the place to discuss syntax questions -- if you'd like to restart the conversation on short lambda syntax, please write to the PHP internals mailing list.

Please further note that this topic has already been discussed quite extensively, and unless you are familiar with LALR(1) parser limitations, your suggestions will likely not be technically feasible (or you need to expand on the implementation tradeoffs you wish to make).