Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 3 commits into from

Conversation

@bwoebi
Copy link
Contributor

bwoebi commented May 1, 2015

Implementation for https://wiki.php.net/rfc/short_closures

@bwoebi bwoebi force-pushed the bwoebi:short_closures branch 2 times, most recently from 2e3c4e8 to 8407062 May 2, 2015
@Kubo2

This comment has been minimized.

Copy link
Contributor

Kubo2 commented May 2, 2015

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.

@smalyshev smalyshev added the RFC label May 8, 2015
@bwoebi bwoebi force-pushed the bwoebi:short_closures branch from 8407062 to 4fec999 Aug 31, 2015
@@ -4873,7 +4909,28 @@ void zend_compile_func_decl(znode *result, zend_ast *ast) /* {{{ */

zend_compile_params(params_ast, return_type_ast);
if (uses_ast) {
zend_compile_closure_uses(uses_ast);
uint32_t i;

This comment has been minimized.

Copy link
@ralt

ralt Aug 31, 2015

Contributor

Is it possible to export this to another function? Growing and growing existing functions is a path to nightmare.

This comment has been minimized.

Copy link
@bwoebi

bwoebi Aug 31, 2015

Author Contributor

yes, this is a simple independent branch which could be easily exported. But these really aren't the issue, but rather when you have interdependent branches...

This comment has been minimized.

Copy link
@ralt

ralt Aug 31, 2015

Contributor

Is it an excuse to not export this one? :-)

@kakserpom

This comment has been minimized.

Copy link

kakserpom commented Sep 12, 2015

What a brilliant feature! Please merge it into 7.0.

@HallofFamer

This comment has been minimized.

Copy link

HallofFamer commented Sep 12, 2015

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

@staabm

This comment has been minimized.

Copy link
Contributor

staabm commented Sep 12, 2015

See RFC

@HallofFamer

This comment has been minimized.

Copy link

HallofFamer commented Sep 12, 2015

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.

@jesseschalken

This comment has been minimized.

Copy link

jesseschalken commented Sep 12, 2015

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.

@kakserpom

This comment has been minimized.

Copy link

kakserpom commented Sep 12, 2015

==> 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 =>>?

@lubosdz

This comment has been minimized.

Copy link

lubosdz commented Sep 12, 2015

~> is hardly legible on high resolution screens.

@hotwer

This comment has been minimized.

Copy link

hotwer commented Sep 12, 2015

The symbol is more accentuated on monospaced fonts

@bwoebi bwoebi force-pushed the bwoebi:short_closures branch from 4fec999 to 30e3691 Sep 22, 2015
@dubpub

This comment has been minimized.

Copy link

dubpub commented Oct 1, 2015

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.

@bwoebi

This comment has been minimized.

Copy link
Contributor Author

bwoebi commented Oct 1, 2015

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.

@nikic

This comment has been minimized.

Copy link
Member

nikic commented Jan 1, 2016

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

@nikic nikic closed this Jan 1, 2016
@kakserpom

This comment has been minimized.

Copy link

kakserpom commented Jan 1, 2016

R.I.P

@ravloony

This comment has been minimized.

Copy link

ravloony commented on 28a1575 Jan 13, 2016

I think it should be "RETURN_TOKEN(T_TILDED_ARROW);" in Zend/zend_language_scanner.l

This comment has been minimized.

Copy link
Owner Author

bwoebi replied Jan 13, 2016

That's the result of having it rebased ... originally the context sensitive lexer RFC hadn't been merged yet.

Anyway, it doesn't really matter as long as the token isn't used as raw string.

@jimgwhit

This comment has been minimized.

Copy link

jimgwhit commented Aug 24, 2016

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.

@mpyw

This comment has been minimized.

Copy link
Contributor

mpyw commented Jul 14, 2017

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

@evgv

This comment has been minimized.

Copy link

evgv commented Aug 11, 2017

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

@KsaR99

This comment has been minimized.

Copy link

KsaR99 commented Aug 13, 2017

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

@im-sunil

This comment has been minimized.

Copy link

im-sunil commented Oct 16, 2017

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.

@anon767

This comment has been minimized.

Copy link

anon767 commented Feb 2, 2018

it could be more python-styled like

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

@DAVIDhaker

This comment has been minimized.

Copy link

DAVIDhaker commented Jun 20, 2018

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.

@mpyw

This comment has been minimized.

Copy link
Contributor

mpyw commented Jun 20, 2018

@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.

@comm1x

This comment has been minimized.

Copy link

comm1x commented Jul 11, 2018

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

@jvasseur

This comment has been minimized.

Copy link

jvasseur commented Jul 11, 2018

-> 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.

@mpyw

This comment has been minimized.

Copy link
Contributor

mpyw commented Jul 12, 2018

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

@comm1x

This comment has been minimized.

Copy link

comm1x commented Jul 12, 2018

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.

@glen-84

This comment has been minimized.

Copy link

glen-84 commented Jul 29, 2018

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.

@php php locked as off topic and limited conversation to collaborators Jul 29, 2018
@nikic

This comment has been minimized.

Copy link
Member

nikic commented Jul 29, 2018

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).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.