Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-23 Thread Rowan Collins
On 23 June 2017 19:43:19 BST, Rasmus Schultz wrote: >Suffice it to say, I understand your arguments and your point of view, >I >just don't agree with it Indeed, as I say, different people want different things from this proposal, and no syntax is going to suit all of them. I

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-23 Thread Rasmus Schultz
I think there is not much point in carrying on this debate. Suffice it to say, I understand your arguments and your point of view, I just don't agree with it - if this new feature produces closures, by my understanding, it's alternate syntax for producing closures, and does not constitute a new

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-21 Thread Pedro Magalhães
On Wed, Jun 21, 2017 at 11:19 PM, Rowan Collins wrote: > > The short form is still constrained to be a single expression, because > otherwise you can't omit the "return" statement; For the sake of discussion, Groovy has optional returns where the last evaluated

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-21 Thread Rowan Collins
On 21/06/2017 15:04, Rasmus Schultz wrote: > > For me (and I am not alone), this feature is NOT a new syntax for closures > > Regardless of why you want it, that's exactly what it is though - another way to declare a closure. > > Even if it has different semantics, the resulting object is

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-21 Thread Rasmus Schultz
> Once you start getting into multi statement closures, all the weird syntax elements that are being proposed just make it harder to read and harder to visually parse. The same is true for current function syntax. But that's what line-breaks are for :-) > Automatically importing variables isn’t

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-21 Thread Rasmus Schultz
> For me (and I am not alone), this feature is NOT a new syntax for closures Regardless of why you want it, that's exactly what it is though - another way to declare a closure. Even if it has different semantics, the resulting object is still an instance of Closure, right? It should pass

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-20 Thread Rowan Collins
On 19 June 2017 21:22:53 BST, Rasmus Schultz wrote: >So what's on the table is a syntax-improved but feature-crippled >variant of >closures, not an all-round replacement? I haven't the time right now to dig out my summary from the mail archives, but this is one of the

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-20 Thread Rasmus Schultz
> I just think your example is an exaggeration to what happens in practice. I think it's an example of what happens with any inconsistent feature in any language. On Tue, Jun 20, 2017 at 9:53 AM, Markus Fischer wrote: > Hello Rasmus, > > On 19.06.17 22:22, Rasmus Schultz

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-20 Thread Ilija Tovilo
Well, the Ruby/Rust syntax would serve us well here too: $things->forEach(|$v| {     foo($v);     bar($v); }); On 19 Jun, 2017, at 09:43 PM, Rasmus Schultz wrote: I actually like this syntax, but what would it look like for multi-statement closures? A nested set of curly

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-20 Thread Markus Fischer
Hello Rasmus, On 19.06.17 22:22, Rasmus Schultz wrote: If I have to factor back and forth between new and old syntax every time a closure changes from one to multiple or back to one statement, then, frankly, what's the point? I think I would just keep using the old syntax, then - for

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-19 Thread Rasmus Schultz
So what's on the table is a syntax-improved but feature-crippled variant of closures, not an all-round replacement? If I have to factor back and forth between new and old syntax every time a closure changes from one to multiple or back to one statement, then, frankly, what's the point? I think I

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-19 Thread Larry Garfield
On 06/19/2017 03:45 PM, Rasmus Schultz wrote: Or maybe it'll look okay if you format the code? $things->forEach({$v => { foo($v); bar($v); }}); Still looks kinda crazy with the closing "}})" though... Multi-line lambdas should use the existing syntax without

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-19 Thread Rasmus Schultz
Or maybe it'll look okay if you format the code? $things->forEach({$v => { foo($v); bar($v); }}); Still looks kinda crazy with the closing "}})" though... On Mon, Jun 19, 2017 at 9:43 PM, Rasmus Schultz wrote: > I actually like this syntax, but

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-19 Thread Rasmus Schultz
I actually like this syntax, but what would it look like for multi-statement closures? A nested set of curly braces around the body would look pretty messy. $things->forEach({$v => { foo($v); bar($v); }}); On Mon, Jun 19, 2017 at 4:43 PM, Levi Morrison wrote: > On Sun, Jun

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-19 Thread Levi Morrison
On Sun, Jun 18, 2017 at 1:44 PM, Ilija Tovilo wrote: > Sorry, I wasn’t aware of that. > > What do you think of the Ruby/Rust style syntax that Levi proposed a while > back? > > $someDict > ->map(|$v| $v * 2) > ->filter(|$v| $v % 3); > > This one has a few advantages:

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-18 Thread Dan Ackroyd
On 18 June 2017 at 19:48, Rasmus Schultz wrote: > > I was referring to the visual ambiguity - the fn($x) part of the syntax is > indistinguishable from a function-call. Only to the same extent that if($x) {} is indistinguishable from a function call. Most people don't have

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-18 Thread Ilija Tovilo
Sorry, I wasn’t aware of that. What do you think of the Ruby/Rust style syntax that Levi proposed a while back? $someDict ->map(|$v| $v * 2) ->filter(|$v| $v % 3); This one has a few advantages: 1. It has syntax (a lot of) developers are already familiar with 2. It has no ambiguities

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-18 Thread Rasmus Schultz
I understand it's not ambiguous to the parser if it's a keyword. I was referring to the visual ambiguity - the fn($x) part of the syntax is indistinguishable from a function-call. On Sun, Jun 18, 2017 at 8:42 PM, Ilija Tovilo wrote: > > I don't agree that the fn keyword

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-18 Thread Ilija Tovilo
> I don't agree that the fn keyword solves the ambiguity problem - it looks > exactly like a function call. Right. But it does solve the ambiguity if `fn` is a keyword which is what the RFC suggests. > On 18 Jun 2017, at 18:40, Rasmus Schultz wrote: > > I don't agree

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-18 Thread Rasmus Schultz
I don't agree that the fn keyword solves the ambiguity problem - it looks exactly like a function call. As for the backslash, my honest reaction is, ugh, please, no more backslashes - PHP (and every other language) uses backslashes for escaping in strings, it already looks pretty awkward in

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-18 Thread Ilija Tovilo
The backslash has actually been one of the earlier options if I remember correctly. I definitely prefer the `fn` keyword as it’s only one character more but adds a better visual hint to the arrow function. I’m also not sure why we’d choose a different arrow (`==>` or `~>`) when the ambiguity

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-15 Thread Björn Larsson
Den 2017-06-15 kl. 15:34, skrev Fleshgrinder: On 6/15/2017 3:29 PM, Björn Larsson wrote: Seems like the constraints on this feature makes it hard to fly, i.e. 1. Not a hackish implementation 2. Non ambiguous syntax 3. Easy to parse & use syntax for the human HackLang then prioritised 2 & 3

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-15 Thread Fleshgrinder
On 6/15/2017 3:29 PM, Björn Larsson wrote: > Seems like the constraints on this feature makes it hard to fly, i.e. > 1. Not a hackish implementation > 2. Non ambiguous syntax > 3. Easy to parse & use syntax for the human > > HackLang then prioritised 2 & 3 making the end-users happy, but > had to

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-15 Thread Björn Larsson
Den 2017-06-10 kl. 10:05, skrev Björn Larsson: Den 2017-06-09 kl. 15:44, skrev Sara Golemon: On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson wrote: If I take the liberty in using the example above on our option list: 1. $someDict->map(fn($v) => $v * 2)->filter(fn($v)

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-10 Thread Niklas Keller
2017-06-10 11:09 GMT+02:00 Stephen Reay : > > > On 10 Jun 2017, at 15:19, Björn Larsson > wrote: > > > > Den 2017-06-09 kl. 22:00, skrev Niklas Keller: > >> 2017-06-09 15:44 GMT+02:00 Sara Golemon : > >> > >>> On Fri, Jun 9,

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-10 Thread Stephen Reay
> On 10 Jun 2017, at 15:19, Björn Larsson wrote: > > Den 2017-06-09 kl. 22:00, skrev Niklas Keller: >> 2017-06-09 15:44 GMT+02:00 Sara Golemon : >> >>> On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson >>> wrote: If I

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-10 Thread Björn Larsson
Den 2017-06-09 kl. 22:00, skrev Niklas Keller: 2017-06-09 15:44 GMT+02:00 Sara Golemon : On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson wrote: If I take the liberty in using the example above on our option list: 1. $someDict->map(fn($v) => $v *

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-10 Thread Björn Larsson
Den 2017-06-09 kl. 15:44, skrev Sara Golemon: On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson wrote: If I take the liberty in using the example above on our option list: 1. $someDict->map(fn($v) => $v * 2)->filter(fn($v) => $v % 3); 2. $someDict->map(function($v) => $v

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-09 Thread Levi Morrison
On Fri, Jun 9, 2017 at 4:43 PM, Rowan Collins wrote: > On 9 June 2017 21:00:48 BST, Niklas Keller wrote: >>2017-06-09 15:44 GMT+02:00 Sara Golemon : >> >>> On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson >> >>>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-09 Thread Rowan Collins
On 9 June 2017 21:00:48 BST, Niklas Keller wrote: >2017-06-09 15:44 GMT+02:00 Sara Golemon : > >> On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson > >> wrote: >> > If I take the liberty in using the example above on our option >list: >> >

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-09 Thread Niklas Keller
2017-06-09 15:44 GMT+02:00 Sara Golemon : > On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson > wrote: > > If I take the liberty in using the example above on our option list: > > 1. $someDict->map(fn($v) => $v * 2)->filter(fn($v) => $v % 3); > > 2.

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-09 Thread Sara Golemon
On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson wrote: > If I take the liberty in using the example above on our option list: > 1. $someDict->map(fn($v) => $v * 2)->filter(fn($v) => $v % 3); > 2. $someDict->map(function($v) => $v * 2)->filter(function($v) => $v % 3); > 3.

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-09 Thread Björn Larsson
Den 2017-06-09 kl. 02:13, skrev Sara Golemon: On Thu, Jun 8, 2017 at 4:56 PM, Björn Larsson wrote: You have a good point here! I think one then should evaluate both the implementation, which apparently is not so great and how the feature itself has been received. I

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-08 Thread Sara Golemon
On Thu, Jun 8, 2017 at 4:56 PM, Björn Larsson wrote: > You have a good point here! I think one then should evaluate > both the implementation, which apparently is not so great and > how the feature itself has been received. > > I mean is it heavily used and what is the

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-08 Thread Björn Larsson
Den 2017-06-08 kl. 19:21, skrev Fleshgrinder: On 6/8/2017 6:28 PM, Rasmus Schultz wrote: it could be a single symbol instead of two even if this can be done without parser ambiguity, it suffers from visual ambiguity with the assignment operator. consider what this would look like if the

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-08 Thread Björn Larsson
Den 2017-06-08 kl. 15:34, skrev Rowan Collins: On 08/06/2017 13:33, Björn Larsson wrote: One reason (not the only one) for me to advocate ==> syntax is that it's the same syntax as HACK I'm not a fan of this logic. Using Hack as a kind of prototyping-ground for PHP features is fine, but

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-08 Thread Fleshgrinder
On 6/8/2017 6:28 PM, Rasmus Schultz wrote: >> it could be a single symbol instead of two > > even if this can be done without parser ambiguity, it suffers from visual > ambiguity with the assignment operator. > > consider what this would look like if the expression itself uses the > assignment

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-08 Thread Rasmus Schultz
> it could be a single symbol instead of two even if this can be done without parser ambiguity, it suffers from visual ambiguity with the assignment operator. consider what this would look like if the expression itself uses the assignment operator... f($x) = $y = $y + $x; versus something

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-08 Thread Sara Golemon
On Thu, Jun 8, 2017 at 9:34 AM, Rowan Collins wrote: > On 08/06/2017 13:33, Björn Larsson wrote: >> >> One reason >> (not the only one) for me to advocate ==> syntax is that it's the >> same syntax as HACK > > > I'm not a fan of this logic. Using Hack as a kind of

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-08 Thread Fleshgrinder
On 6/7/2017 9:45 PM, Rasmus Schultz wrote: >> the `fn($a, $b) => $a + $b ** $c` syntax suddenly becomes an acceptable > compromise. > > I have to second that. > > I might even propose to shorten it from "fn" to just "f" - the resulting > syntax then resembles a mathematical predicate :-) > I

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-08 Thread Rowan Collins
On 08/06/2017 13:33, Björn Larsson wrote: One reason (not the only one) for me to advocate ==> syntax is that it's the same syntax as HACK I'm not a fan of this logic. Using Hack as a kind of prototyping-ground for PHP features is fine, but since they don't have the same decision-making

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-08 Thread Björn Larsson
Den 2017-06-07 kl. 17:20, skrev Stephen Reay: On 7 Jun 2017, at 20:37, Björn Larsson wrote: Well, one reason to use fn or even lambda was to signal that this is different then a regular function. When it comes to number of keystrokes I guess that some inspiration

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-07 Thread Rasmus Schultz
> the `fn($a, $b) => $a + $b ** $c` syntax suddenly becomes an acceptable compromise. I have to second that. I might even propose to shorten it from "fn" to just "f" - the resulting syntax then resembles a mathematical predicate :-) On Wed, Jun 7, 2017 at 5:20 PM, Stephen Reay

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-07 Thread Stephen Reay
> On 7 Jun 2017, at 20:37, Björn Larsson wrote: > > Well, one reason to use fn or even lambda was to signal that this is > different then a regular function. > > When it comes to number of keystrokes I guess that some inspiration > has been taken from other languages

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-07 Thread Björn Larsson
Den 2017-06-06 kl. 06:38, skrev Stephen Reay: On 6 Jun 2017, at 03:18, Björn Larsson wrote: Den 2017-06-05 kl. 21:23, skrev Ryan Pallas: On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder wrote: On 6/5/2017 9:03 PM, Ryan Pallas wrote: However,

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-06 Thread Fleshgrinder
On 6/6/2017 6:38 AM, Stephen Reay wrote: > As someone who sees limited appeal in short closures (Ok, they may > make for slightly simpler constructs that are slightly too complex > for a regular “collect” type collection method), I see a *lot* of > people spending a *lot* of time to save typing 8

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-05 Thread Stephen Reay
> > On 6 Jun 2017, at 03:18, Björn Larsson wrote: > > Den 2017-06-05 kl. 21:23, skrev Ryan Pallas: > >> On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder wrote: >> >>> On 6/5/2017 9:03 PM, Ryan Pallas wrote: However, ($obj) -> $var is valid

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-05 Thread Björn Larsson
Den 2017-06-05 kl. 21:23, skrev Ryan Pallas: On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder wrote: On 6/5/2017 9:03 PM, Ryan Pallas wrote: However, ($obj) -> $var is valid variable property syntax. Gosh, we really have support for everything. :D That one is even very

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-05 Thread Rowan Collins
On 05/06/2017 20:09, Fleshgrinder wrote: How about ~> which I at least cannot think of any place it is used at all. ~ in binary negation and the only place we use it (I checked the language parser this time to make sure). We've come full circle: that was actually the syntax proposed in Bob

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-05 Thread Ryan Pallas
On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder wrote: > On 6/5/2017 9:03 PM, Ryan Pallas wrote: > > However, ($obj) -> $var is valid variable property syntax. > > > > Gosh, we really have support for everything. :D That one is even very > important for stuff like `(new

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-05 Thread Fleshgrinder
On 6/5/2017 9:03 PM, Ryan Pallas wrote: > However, ($obj) -> $var is valid variable property syntax. > Gosh, we really have support for everything. :D That one is even very important for stuff like `(new A)->f()`. How about ~> which I at least cannot think of any place it is used at all. ~ in

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-05 Thread Ryan Pallas
On Jun 5, 2017 12:53 PM, "Fleshgrinder" wrote: On 6/5/2017 8:36 PM, Rasmus Schultz wrote: > Ugh, you're right, that's totally unreadable... the => is far too ambiguous > with array syntax, I agree. > > How about just a thin arrow? > > (params) -> expr > > If the parens

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-05 Thread Fleshgrinder
On 6/5/2017 8:36 PM, Rasmus Schultz wrote: > Ugh, you're right, that's totally unreadable... the => is far too ambiguous > with array syntax, I agree. > > How about just a thin arrow? > > (params) -> expr > > If the parens around params were required, it's not ambiguous with the > trailing

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-05 Thread Rasmus Schultz
Ugh, you're right, that's totally unreadable... the => is far too ambiguous with array syntax, I agree. How about just a thin arrow? (params) -> expr If the parens around params were required, it's not ambiguous with the trailing -- operator, is it? $foo->bar(($baz) -> $baz + 1);

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-05 Thread Björn Larsson
Den 2017-06-05 kl. 19:55, skrev Rowan Collins: On 5 June 2017 18:17:06 BST, Fleshgrinder wrote: Could someone explain me again what the problem with the simple fat-arrow and normal parenthesis is? Cannot find it anymore (too many messages in too many thread I guess). I

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-05 Thread Fleshgrinder
On 6/5/2017 7:55 PM, Rowan Collins wrote: > I think it's not just a case of implementation problems, it's actually > ambiguous with current syntax: > > $foo = array( ($x) => 42 ); > > Sure, those inner brackets are redundant, so it's not likely to break much > actual code, but it's kind of

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-05 Thread Rowan Collins
On 5 June 2017 18:17:06 BST, Fleshgrinder wrote: >Could someone explain me again what the problem with the simple >fat-arrow and normal parenthesis is? Cannot find it anymore (too many >messages in too many thread I guess). I would guess that it has to do >with the

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-05 Thread Fleshgrinder
On 6/5/2017 6:17 PM, Larry Garfield wrote: > 3 > 4 > 1. > > 2 is not even worth considering and I'd almost prefer not having arrow > functions if their syntax is going to be that self-defeating. > > I also see no reason to include both by-value and by-reference binding > Arrow functions are for

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-05 Thread Larry Garfield
On 06/05/2017 09:19 AM, Rasmus Schultz wrote: Of the proposed options, I'd prefer the double fat-arrow ==> However, I remain of the opinion that all of those syntaxes are work-arounds to ambiguity concerns for cases that likely don't actually occur in real-world codebases. I don't understand

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-05 Thread Rasmus Schultz
Of the proposed options, I'd prefer the double fat-arrow ==> However, I remain of the opinion that all of those syntaxes are work-arounds to ambiguity concerns for cases that likely don't actually occur in real-world codebases. I don't understand the motivation to design or optimize based on

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-05 Thread Björn Larsson
Den 2017-06-01 kl. 18:58, skrev Theodore Brown: On Tuesday, May 30, 2017 at 12:58 PM, Levi Morrison wrote: Based on the discussion there are a few different syntax choices people liked. Overall it's a feature that people seem to want but everyone seems to prefer a different syntax choice. 1.

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-06-01 Thread Theodore Brown
On Tuesday, May 30, 2017 at 12:58 PM, Levi Morrison wrote: > Based on the discussion there are a few different syntax choices > people liked. Overall it's a feature that people seem to want but > everyone seems to prefer a different syntax choice. > > 1. fn(params) => expr > 2. function(params)

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-31 Thread ilija . tovilo
I think it’s worth noting that the people most excited about arrow functions are probably the ones with a more functional approach. Those kinds of side effects are usually avoided. I also have nothing against capturing by reference. Given the last example: fn($item) => $array[] = $item All you

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-31 Thread Levi Morrison
> I can’t think of a scenario where capturing by reference would be helpful in > a single line closure. function($item) use($array) { return $array[] = $item; } It's actually one of the first closures I discovered in the wild when looking for closures that would be candidates for

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-31 Thread ilija . tovilo
My preferences: 1, 3, 4, 5, (big void),  2. I actually like 4 the most but I get that that might not be practical if it leads to unexpected behaviour. I can’t think of a scenario where capturing by reference would be helpful in a single line closure. 5 just adds additional complexity with no

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-31 Thread Rowan Collins
On 31 May 2017 14:48:03 BST, Levi Morrison wrote: >On Wed, May 31, 2017 at 7:36 AM, Rowan Collins > wrote: >> I was just pondering alternative approaches to stop the => token >being ambiguous, and wondered if surrounding the whole expression with >braces

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-31 Thread Levi Morrison
On Wed, May 31, 2017 at 7:36 AM, Rowan Collins wrote: > On 30 May 2017 18:58:14 BST, Levi Morrison wrote: >>Internals, >> >>The previous discussion thread has died down significantly and so I'd >>like to start a new one to refocus. This message has some

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-31 Thread Rowan Collins
On 30 May 2017 18:58:14 BST, Levi Morrison wrote: >Internals, > >The previous discussion thread has died down significantly and so I'd >like to start a new one to refocus. This message has some redundant >information by design so people don't have to reference the other >thread so

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-30 Thread Björn Larsson
Den 2017-05-31 kl. 00:26, skrev Levi Morrison: On Tue, May 30, 2017 at 3:37 PM, Björn Larsson wrote: Den 2017-05-30 kl. 21:40, skrev Derick Rethans: On Tue, 30 May 2017, Levi Morrison wrote: Internals, The previous discussion thread has died down significantly

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-30 Thread Levi Morrison
On Tue, May 30, 2017 at 3:37 PM, Björn Larsson wrote: > Den 2017-05-30 kl. 21:40, skrev Derick Rethans: > >> On Tue, 30 May 2017, Levi Morrison wrote: >> >>> Internals, >>> >>> The previous discussion thread has died down significantly and so I'd >>> like to start a new

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-30 Thread Björn Larsson
Den 2017-05-30 kl. 21:40, skrev Derick Rethans: On Tue, 30 May 2017, Levi Morrison wrote: Internals, The previous discussion thread has died down significantly and so I'd like to start a new one to refocus. This message has some redundant information by design so people don't have to

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-30 Thread Derick Rethans
On Tue, 30 May 2017, Levi Morrison wrote: > Internals, > > The previous discussion thread has died down significantly and so I'd > like to start a new one to refocus. This message has some redundant > information by design so people don't have to reference the other > thread so much. > > Based

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-30 Thread Björn Larsson
Den 2017-05-30 kl. 20:24, skrev Levi Morrison: On Tue, May 30, 2017 at 12:16 PM, Björn Larsson wrote: Den 2017-05-30 kl. 19:58, skrev Levi Morrison: Internals, The previous discussion thread has died down significantly and so I'd like to start a new one to refocus.

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-30 Thread Levi Morrison
>> You mentioned ability to explicitly specify binding as a possible extension. >> However >> >> [$var1, $var2]() >> >> is not necessarily failing right now, it may be a valid array callable. >> >> Nikita > > As already mentioned we must maintain a leading `=` or `&`: > > [=, $var1, $var2]()

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-30 Thread Levi Morrison
On Tue, May 30, 2017 at 12:36 PM, Nikita Popov wrote: > On Tue, May 30, 2017 at 8:24 PM, Levi Morrison wrote: >> >> On Tue, May 30, 2017 at 12:16 PM, Björn Larsson >> wrote: >> > Den 2017-05-30 kl. 19:58, skrev Levi Morrison: >> >>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-30 Thread Nikita Popov
On Tue, May 30, 2017 at 8:24 PM, Levi Morrison wrote: > On Tue, May 30, 2017 at 12:16 PM, Björn Larsson > wrote: > > Den 2017-05-30 kl. 19:58, skrev Levi Morrison: > >> > >> Internals, > >> > >> The previous discussion thread has died down significantly

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-30 Thread Levi Morrison
On Tue, May 30, 2017 at 12:16 PM, Björn Larsson wrote: > Den 2017-05-30 kl. 19:58, skrev Levi Morrison: >> >> Internals, >> >> The previous discussion thread has died down significantly and so I'd >> like to start a new one to refocus. This message has some redundant >>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-30 Thread Björn Larsson
Den 2017-05-30 kl. 19:58, skrev Levi Morrison: Internals, The previous discussion thread has died down significantly and so I'd like to start a new one to refocus. This message has some redundant information by design so people don't have to reference the other thread so much. Based on the

[PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

2017-05-30 Thread Levi Morrison
Internals, The previous discussion thread has died down significantly and so I'd like to start a new one to refocus. This message has some redundant information by design so people don't have to reference the other thread so much. Based on the discussion there are a few different syntax choices