# [RFC][Discuss] Arrow Functions - Thread: https://externals.io/message/98045 - Original archive: https://news-web.php.net/php.internals/98045 - Started by Levi Morrison on 2017-01-30T17:55:07+00:00 - Messages: 91 - RFC: Arrow Functions (Obsolete) — https://externals.io/rfc/arrow_functions.md - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/98045.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #98045 — Levi Morrison — 2017-01-30T17:55:07+00:00 URL: https://externals.io/message/98045#98045 Bob Weinand and I are happy to announce that the [Arrow Functions][1] RFC is moving into the public discussion phase. We have been collaborating on this RFC for many months now and finally have a proposal we are happy to discuss in the open. Here is an example of an existing closure: function ($x) use ($arr) { return $arr[$x]; } This RFC proposes syntax and semantics to simplify this common usage to: fn($x) => $arr[$x] More details are in the RFC. The [implementation][2] currently has no known issues and is ready for you to download, build and test, which we encourage you to do. We look forward to a productive discussion period and are happy to answer questions. For historical purposes, the revision of this RFC is currently at [1485798604][3]. [1]: https://wiki.php.net/rfc/arrow_functions [2]: https://github.com/morrisonlevi/php-src/tree/arrow_functions [3]: https://wiki.php.net/rfc/arrow_functions?rev=1485798604 --- ## #98047 — Niklas Keller — 2017-01-30T18:42:29+00:00 URL: https://externals.io/message/98045#98047 · In reply to: #98045 Levi Morrison schrieb am Mo., 30. Jan. 2017, 18:55: > Bob Weinand and I are happy to announce that the [Arrow Functions][1] > RFC is moving into the public discussion phase. We have been > collaborating on this RFC for many months now and finally have a > proposal we are happy to discuss in the open. > > Here is an example of an existing closure: > > function ($x) use ($arr) { > return $arr[$x]; > } > > This RFC proposes syntax and semantics to simplify this common usage to: > > fn($x) => $arr[$x] > > More details are in the RFC. The [implementation][2] currently has no > known issues and is ready for you to download, build and test, which > we encourage you to do. > https://3v4l.org has a feature branch for arrow functions, you can find it in the preview select box for playing around and in the RFC tab after a full execution. We look forward to a productive discussion period and are happy to > answer questions. > > For historical purposes, the revision of this RFC is currently at > [1485798604][3]. > > [1]: https://wiki.php.net/rfc/arrow_functions > [2]: https://github.com/morrisonlevi/php-src/tree/arrow_functions > [3]: https://wiki.php.net/rfc/arrow_functions?rev=1485798604 --- ## #98055 — Guy Marriott — 2017-01-30T21:42:15+00:00 URL: https://externals.io/message/98045#98055 · In reply to: #98047 > Levi Morrison schrieb am Mo., 30. Jan. 2017, 18:55: > > > […] > > https://3v4l.org has a feature branch for arrow functions, you can find > it > in the preview select box for playing around and in the RFC tab after a > full execution. > > We look forward to a productive discussion period and are happy to > > […] > Looking good. Really excited for something like this in PHP. Just a heads up, the section in the introduction that refers to other languages having similar syntax still has a TODO in it. I agree that some references to other languages' implementations (ES6 comes to mind) would be a nice addition. Awesome work, Guy --- ## #98057 — Rowan Collins — 2017-01-30T23:05:19+00:00 URL: https://externals.io/message/98045#98057 · In reply to: #98045 > Bob Weinand and I are happy to announce that the [Arrow Functions][1] > RFC is moving into the public discussion phase. We have been > collaborating on this RFC for many months now and finally have a > proposal we are happy to discuss in the open. > > [1]: https://wiki.php.net/rfc/arrow_functions Firstly, I like this proposal a lot more than the previous, so thank you for working on this based on previous discussion. In particular, I'm glad to see it focused on single expressions with implicit return, as I think that's where it has most value. A few comments: > ThisRFC does support type declarations for parameters and return types. An example of the syntax for this would be good, particularly how the return type fits the syntax (which may conflict with my suggestion below). > The implementation currently supports static closures, for example |static fn($x) => static::get($x)|. I was initially confused by this paragraph, because I was unaware that static closures existed. I'm still not entirely sure *why* they exist, but for anyone else wondering, here's what they currently look like: http://php.net/manual/en/functions.anonymous.php#functions.anonymous-functions.static Finally, my personal preference is still for a syntax that encloses the whole definition somehow, and since we need the fn keyword anyway, I wonder about stretching the brackets around the whole definition, e.g. fn($x => $x * 2). Personally, I find this: ->reduce(fn($tmp, $v => $tmp + $v), 0) easier to mentally parse than this: ->reduce(fn($tmp, $v) => $tmp + $v, 0) because you only have to match brackets to see where the ", 0" belongs. I also think it would make combining closures clearer if they were nested rather than associative (I guess those used to reading Haskell will probably disagree with me): $complement = fn($f) => fn(... $args) => !$f(... $args) vs $complement = fn($f => fn(... $args => !$f(... $args))) Regards, -- Rowan Collins [IMSoP] --- ## #98058 — Levi Morrison — 2017-01-30T23:31:15+00:00 URL: https://externals.io/message/98045#98058 · In reply to: #98057 > > > […] > > > Firstly, I like this proposal a lot more than the previous, so thank you for > working on this based on previous discussion. In particular, I'm glad to see > it focused on single expressions with implicit return, as I think that's > where it has most value. > > A few comments: > > > […] > > > An example of the syntax for this would be good, particularly how the return > type fits the syntax (which may conflict with my suggestion below). They go in the same places as regular functions. I'll update the RFC later with examples, but for now here is an example that takes an integer and returns it, which type declarations: fn (int $x): int => $x --- ## #98059 — Andrea Faulds — 2017-01-31T01:12:07+00:00 URL: https://externals.io/message/98045#98059 · In reply to: #98045 Hi Levi, Levi Morrison wrote: > Here is an example of an existing closure: > > function ($x) use ($arr) { > return $arr[$x]; > } > > This RFC proposes syntax and semantics to simplify this common usage to: > > fn($x) => $arr[$x] > Is it necessary to introduce a new keyword, fn? I think you'd get a similar benefit from: function($x) => $arr[$x] Likewise, is it necessary to restrict auto-capture to the => syntax? Couldn't we allow the following? function ($x) { return $arr[$x]; } That being said, I broadly support your goals. -- Andrea Faulds https://ajf.me/ --- ## #98060 — David Walker — 2017-01-31T04:41:01+00:00 URL: https://externals.io/message/98045#98060 · In reply to: #98059 > Hi Levi, > > Levi Morrison wrote: > > […] > > Is it necessary to introduce a new keyword, fn? > > I think you'd get a similar benefit from: > > function($x) => $arr[$x] > > Likewise, is it necessary to restrict auto-capture to the => syntax? > Couldn't we allow the following? > > function ($x) { > return $arr[$x]; > } > This looks too similar to the current syntax, just ignoring the use() statement. I would add a concurance that => syntax is slightly awkward when used within an array element $a = [ 'func' => fn($x) => Class::method($x), ]; But I'm not overly certain of a different syntax to handle this. I would support expanding to function over fn, to make it more readable/keep the same reserved word. (Although not too certain to the complexity in the parser) Otherwise +1, I like this. -- Dave --- ## #98061 — Stephen Reay — 2017-01-31T04:53:32+00:00 URL: https://externals.io/message/98045#98061 · In reply to: #98059 Hi Andrea, All, > > > Is it necessary to introduce a new keyword, fn? > > I think you'd get a similar benefit from: > > function($x) => $arr[$x] > > Likewise, is it necessary to restrict auto-capture to the => syntax? Couldn't we allow the following? > > function ($x) { > return $arr[$x]; > } > I agree that the `fn` keyword isn’t really necessary. I’ve never quite understood how arrow functions with implied returns etc are supposed to make for *more* readable code, but if they’re going to be part of the language please at least keep some consistency with regular closures. In the case that regular closures got auto-capture, would a `use($foo, $bar, $baz)` segment on a closure still be honoured (i.e. disable auto-capture), and would it have any impact (positive or negative) on performance/memory usage? After several years of JS closure ‘fun’ I kind of like that with PHP you only inherit the variables you explicitly `use()` in closures. Cheers Stephen --- ## #98062 — Marc Bennewitz — 2017-01-31T05:44:25+00:00 URL: https://externals.io/message/98045#98062 · In reply to: #98061 Am 31.01.2017 um 05:53 schrieb Stephen Reay: > Hi Andrea, All, > > > […] > > I agree that the `fn` keyword isn’t really necessary. I’ve never quite understood how arrow functions with implied returns etc are supposed to make for *more* readable code, but if they’re going to be part of the language please at least keep some consistency with regular closures. > > In the case that regular closures got auto-capture, would a `use($foo, $bar, $baz)` segment on a closure still be honoured (i.e. disable auto-capture), and would it have any impact (positive or negative) on performance/memory usage? After several years of JS closure ‘fun’ I kind of like that with PHP you only inherit the variables you explicitly `use()` in closures. I like the general idea, too. But with similar feelings for: - Introducing a second keyword for closures is confusing - and mor confusing if they are basically the same words - Also I like the "use" keyword you have to define your variables -> Would it be helpful to allow "function () use (*) {}" to inline all available variables? - Or based on Rowans idea to stretching the brackets but using the function keyword: function($x => $arr[$x]) Thanks Marc > > Cheers > > Stephen --- ## #98064 — Nikita Nefedov — 2017-01-31T08:24:20+00:00 URL: https://externals.io/message/98045#98064 · In reply to: #98045 > Bob Weinand and I are happy to announce that the [Arrow Functions][1] > RFC is moving into the public discussion phase. We have been > collaborating on this RFC for many months now and finally have a > proposal we are happy to discuss in the open. > > Here is an example of an existing closure: > > function ($x) use ($arr) { > return $arr[$x]; > } > > This RFC proposes syntax and semantics to simplify this common usage to: > > fn($x) => $arr[$x] > > More details are in the RFC. The [implementation][2] currently has no > known issues and is ready for you to download, build and test, which > we encourage you to do. > > We look forward to a productive discussion period and are happy to > answer questions. > > For historical purposes, the revision of this RFC is currently at > [1485798604][3]. > > [1]: https://wiki.php.net/rfc/arrow_functions > [2]: https://github.com/morrisonlevi/php-src/tree/arrow_functions > [3]: https://wiki.php.net/rfc/arrow_functions?rev=1485798604 Hey Levi, Bob, that looks very good. The fn prefix is peculiar yes but it's alright, it doesn't harm neither readability nor writability, it even has some precedences in other languages (think Rust, Elixir) and as we all know it is necessary for parser. Thanks for the work, I hope it lands in PHP. --- ## #98067 — Michael Wallner — 2017-01-31T10:23:33+00:00 URL: https://externals.io/message/98045#98067 · In reply to: #98061 > Hi Andrea, All, > > > […] > > I agree that the `fn` keyword isn’t really necessary. I’ve never > quite understood how arrow functions with implied returns etc are > supposed to make for *more* readable code, but if they’re going to be > part of the language please at least keep some consistency with > regular closures. Yes, I also think that keeping the function keyword would be better. > > In the case that regular closures got auto-capture, would a > `use($foo, $bar, $baz)` segment on a closure still be honoured (i.e. > disable auto-capture), and would it have any impact (positive or > negative) on performance/memory usage? After several years of JS > closure ‘fun’ I kind of like that with PHP you only inherit the > variables you explicitly `use()` in closures. Wouldn't there be just too many existing closures, which do not use `use` but (maybe) expect a clean scope? -- Regards, Mike --- ## #98069 — Bob Weinand — 2017-01-31T11:14:47+00:00 URL: https://externals.io/message/98045#98069 · In reply to: #98067 Hey, > Am 31.01.2017 um 11:23 schrieb Michael Wallner : > > > > […] > > Yes, I also think that keeping the function keyword would be better. > > > […] > > Wouldn't there be just too many existing closures, which do not use > `use` but (maybe) expect a clean scope? The RFC is exclusively proposing single-expression short Closures. We do NOT want multi-statement short Closures; it is a *feature* that generic Closures need an "use ($foo, $bar)". This vastly improves readability and debuggability - it basically tells you whether the variables inside the code are imported or not. As Stephen Reay notes: > > […] So, auto-import for generic Closures definitely isn't an option. Just on short, single-line Closures there is no benefit to "use ()", as EVERY variable used in the short Closure is supposed to be an imported variable. There is no point in forcing the user to distinguish between imported and local variable here. Also, using "fn" in favor of "function" has the advantage of less clutter in one line. Compare array_map(fn($x) => $x + 1) to array_map(function($x) => $x + 1) The syntactical construction is already pretty clearly showing what's going on. The "function" keyword itself is already larger than the whole body. It distracts while reading the actual code. Additionally, using "fn" is optically highlighting the fact that it's a short-Closure with auto-import and not a normal Closure with explicit import. Thanks, Bob --- ## #98070 — Yasuo Ohgaki — 2017-01-31T11:38:53+00:00 URL: https://externals.io/message/98045#98070 · In reply to: #98045 Hi Levi, > This RFC proposes syntax and semantics to simplify this common usage to: > > fn($x) => $arr[$x] > Could you explain why fn() cannot be removed like ES2015. Rowan's syntax sounds attractive to me if fn() cannot be removed. fn($x => $x * 2) Or since many of us like "function", it could be function($x => $x * 2) I don't have strong preference, but some may have. I suggest separate vote into 2 votes. - Introduce arrow function - Prefered syntax Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #98071 — Niklas Keller — 2017-01-31T11:53:48+00:00 URL: https://externals.io/message/98045#98071 · In reply to: #98069 2017-01-31 12:14 GMT+01:00 Bob Weinand : > Hey, > > > […] > > > The RFC is exclusively proposing single-expression short Closures. > We do NOT want multi-statement short Closures; it is a *feature* that > generic Closures need an "use ($foo, $bar)". > This vastly improves readability and debuggability - it basically tells > you whether the variables inside the code are imported or not. As Stephen > Reay notes: > > […] > > > So, auto-import for generic Closures definitely isn't an option. > Just on short, single-line Closures there is no benefit to "use ()", as > EVERY variable used in the short Closure is supposed to be an imported > variable. There is no point in forcing the user to distinguish between > imported and local variable here. > > Also, using "fn" in favor of "function" has the advantage of less clutter > in one line. Compare > > array_map(fn($x) => $x + 1) > > to > > array_map(function($x) => $x + 1) > "function" is actually easier to recognize than "fn" for me. Humans read things by the first and last letter + contained letters, they don't read each letter separately, so a little bit longer keyword doesn't hurt readability, it might be even improved, because "function" is a keyword people are used to. And it comes with the benefit of no BC break, because "function" is already a keyword. Also updating array_map(function ($x) => 2 * $x, [...]); to array_map(function ($x) use (...) { ... }, [...]); is a little bit easier then, just in case you need an additional statement there. > The syntactical construction is already pretty clearly showing what's > going on. The "function" keyword itself is already larger than the whole > body. Now we're counting chars again instead of keeping the focus on actual readability? > It distracts while reading the actual code. > I disagree here, as mentioned above. > Additionally, using "fn" is optically highlighting the fact that it's a > short-Closure with auto-import and not a normal Closure with explicit > import. > > Thanks, > Bob I think I prefer "function" instead of "fn", but I can also live with "fn". Regards, Niklas --- ## #98072 — Nicolas Grekas — 2017-01-31T12:06:25+00:00 URL: https://externals.io/message/98045#98072 · In reply to: #98070 Or just drop any "fn" or "function" keyword, eg ($x, $y) => foo($x, $y); array_map(($x) => $x + 1); ? --- ## #98073 — Yasuo Ohgaki — 2017-01-31T12:15:45+00:00 URL: https://externals.io/message/98045#98073 · In reply to: #98072 On Tue, Jan 31, 2017 at 9:06 PM, Nicolas Grekas < nicolas.grekas+php@gmail.com> wrote: > Or just drop any "fn" or "function" keyword, eg > > ($x, $y) => foo($x, $y); > > array_map(($x) => $x + 1); > > ? > I like your syntax if it cannot be like ES2015 syntax. -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #98074 — Alain Williams — 2017-01-31T12:20:56+00:00 URL: https://externals.io/message/98045#98074 · In reply to: #98072 > Or just drop any "fn" or "function" keyword, eg > > ($x, $y) => foo($x, $y); > > array_map(($x) => $x + 1); That has the great advantage of being much as Javascript does this. https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/Arrow_functions -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include : > > > […] > > That has the great advantage of being much as Javascript does this. > > https://developer.mozilla.org/en/docs/Web/JavaScript/ > Reference/Functions/Arrow_functions > > IMO it'll be hard to detect arrow function then. Consider an example: $y = 'a'; $x = 1; $a = [ $y => 'b', ($x) => $x + 1, ]; > -- > Alain Williams > Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT > Lecturer. > +44 (0) 787 668 0256 http://www.phcomp.co.uk/ > Parliament Hill Computers Ltd. Registration Information: > http://www.phcomp.co.uk/contact.php > #include > > -- > > > > -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com --- ## #98077 — Niklas Keller — 2017-01-31T12:38:33+00:00 URL: https://externals.io/message/98045#98077 · In reply to: #98074 Alain Williams schrieb am Di., 31. Jan. 2017, 13:20: > > > […] > > That has the great advantage of being much as Javascript does this. > > > https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/Arrow_functions As noted in the RFC, this isn't possible due to ambiguities with array keys and yield expressions with keys. Regards, Niklas > -- > Alain Williams > Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT > Lecturer. > +44 (0) 787 668 0256 http://www.phcomp.co.uk/ > Parliament Hill Computers Ltd. Registration Information: > http://www.phcomp.co.uk/contact.php > #include > As noted in the RFC, this isn't possible due to ambiguities with array > keys and yield expressions with keys. > There are not ambiguities technically, so it is possible if we want to: $a = [ $y => 'b', ($x) => $x + 1, // key, value pair ]; $a = [ $y => 'b', (($x) => $x + 1), // closure ]; --- ## #98079 — Niklas Keller — 2017-01-31T13:03:37+00:00 URL: https://externals.io/message/98045#98079 · In reply to: #98078 Nicolas Grekas schrieb am Di., 31. Jan. 2017, 13:45: > > […] > > There are not ambiguities technically, so it is possible if we want to: > > $a = [ > $y => 'b', > ($x) => $x + 1, // key, value pair > ]; > > $a = [ > $y => 'b', > (($x) => $x + 1), // closure > ]; > Well, it is ambiguous. Your solution just arbitrarily resolves it to one of them. But as far as I know there are more problems like supporting types that make it quite complicated with that syntax. Regards, Niklas --- ## #98081 — Yasuo Ohgaki — 2017-01-31T13:39:14+00:00 URL: https://externals.io/message/98045#98081 · In reply to: #98070 Hi Levi, > > > > […] > > Could you explain why fn() cannot be removed like ES2015. I guess current PHP parser has to determine token type as they processed. So distinguished keyword is needed. I don't have problem with the proposed syntax. Large change is not preferred and current way should be faster. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #98083 — Larry Garfield — 2017-01-31T17:29:32+00:00 URL: https://externals.io/message/98045#98083 · In reply to: #98069 > > […] > > The RFC is exclusively proposing single-expression short Closures. > We do NOT want multi-statement short Closures; it is a *feature* that generic Closures need an "use ($foo, $bar)". > This vastly improves readability and debuggability - it basically tells you whether the variables inside the code are imported or not. As Stephen Reay notes: > > […] > > So, auto-import for generic Closures definitely isn't an option. > Just on short, single-line Closures there is no benefit to "use ()", as EVERY variable used in the short Closure is supposed to be an imported variable. There is no point in forcing the user to distinguish between imported and local variable here. > > Also, using "fn" in favor of "function" has the advantage of less clutter in one line. Compare > > array_map(fn($x) => $x + 1) > > to > > array_map(function($x) => $x + 1) > > The syntactical construction is already pretty clearly showing what's going on. The "function" keyword itself is already larger than the whole body. It distracts while reading the actual code. > Additionally, using "fn" is optically highlighting the fact that it's a short-Closure with auto-import and not a normal Closure with explicit import. > > Thanks, > Bob I must agree with Bob and the other authors. The entire point of this RFC is to reduce the amount of typing, and therefore reading, that goes into using simple closures as first-class values. Using longer keywords instead of shorter ones is counter to that aim. It sounds like the earlier proposal of keyword-less closures isn't technically feasible or it would make sense to argue for that. My question is why there's no mention of HHVM short closures, or the previous RFC to take that approach. See: https://docs.hhvm.com/hack/lambdas/introduction If there's a good reason to not use that syntax, OK, but that should be stated explicitly in the RFC with links to both HHVM and to the previous short-closure RFC. I also echo the previous call to clarify with examples how types would be used, syntactically. Since there is no "return" keyword used, that implies that no "yield" keyword can be used, either. That is, arrow-function generators are not supported. Is that correct? (In context they may not make sense to have, but that should be clarified explicitly in the RFC.) Overall I am +1 on this RFC. --Larry Garfield --- ## #98084 — Michael Morris — 2017-01-31T18:16:27+00:00 URL: https://externals.io/message/98045#98084 · In reply to: #98083 On Tue, Jan 31, 2017 at 12:29 PM, Larry Garfield wrote: > > > > […] > > I must agree with Bob and the other authors. The entire point of this RFC > is to reduce the amount of typing, and therefore reading, that goes into > using simple closures as first-class values. Using longer keywords instead > of shorter ones is counter to that aim. It sounds like the earlier > proposal of keyword-less closures isn't technically feasible or it would > make sense to argue for that. > > My question is why there's no mention of HHVM short closures, or the > previous RFC to take that approach. See: > > https://docs.hhvm.com/hack/lambdas/introduction > > > For what it's worth I'd rather look at array_map( $x ==> $x + 1); than array_map( fn($x) => $x + 1 ) Not to mention the former isn't a bc break. --- ## #98086 — Levi Morrison — 2017-01-31T18:34:12+00:00 URL: https://externals.io/message/98045#98086 · In reply to: #98045 > Bob Weinand and I are happy to announce that the [Arrow Functions][1] > RFC is moving into the public discussion phase. We have been > collaborating on this RFC for many months now and finally have a > proposal we are happy to discuss in the open. > > Here is an example of an existing closure: > > function ($x) use ($arr) { > return $arr[$x]; > } > > This RFC proposes syntax and semantics to simplify this common usage to: > > fn($x) => $arr[$x] > > More details are in the RFC. The [implementation][2] currently has no > known issues and is ready for you to download, build and test, which > we encourage you to do. > > We look forward to a productive discussion period and are happy to > answer questions. > > For historical purposes, the revision of this RFC is currently at > [1485798604][3]. > > [1]: https://wiki.php.net/rfc/arrow_functions > [2]: https://github.com/morrisonlevi/php-src/tree/arrow_functions > [3]: https://wiki.php.net/rfc/arrow_functions?rev=1485798604 Thank you to everyone who has participated in the discussion so far. Several people have asked for examples of type declarations. I have updated the RFC accordingly and also added an example for by-ref parameters and returns. Here are the examples: fn (array $x) => $x fn (): int => 42 fn &(array &$xs) => $xs I have also made some minor improvements to the formatting in various places. --- Next page: https://externals.io/message/98045.md?page=2