On Thu, 14 Mar 2019 at 15:10, Benjamin Morel
email@example.com> wrote:> The problem, as I understand it, is not avoiding ambiguity, it's avoiding >> lookahead. > > > You're right, I was only thinking about resolving the ambiguity with array > keys. It's too bad if the parser implementation considerations take > precedence over the purity of the language >I don't agree that this has anything to do with "purity". If JS didn't have => syntax, why would "fn is a shorter keyword than function" not be a good enough reason to go with this syntax? I think it's equally valid to say that it would be a shame for one syntax shortcut to take precedence over the consistency and maintainability of everything else in the language. Is it really that important to save two key strokes per closure?> Would that solve the parser problem? BC-wise, I don't think this would be > much of a problem: I have yet to see array keys enclosed with parentheses > in PHP codebases. >A quick regex search in a code base I had to hand found a few instances of casts, like [(string)$foo => $bar], but indeed no instances of bracketed variables. However, it would feel rather bizarre to be able to write this: [ $x+1 => $foo ] But not this: [ ($x+1) => $foo ] Which I think would have to be the implication for this to make the parsing any easier. On Thu, 14 Mar 2019 at 15:38, David Rodrigues firstname.lastname@example.org> wrote:> maybe using  instead of ()? For instance: "[$x] => $x + 1". PHP don't supports and array as key, so maybe it will not causes any conflict.Again, I think this solves the ambiguity but not the parsing, although I could be wrong. Consider parsing these three expressions: [ [ $foo ] ] # Nested arrays [ [ $foo => $bar ] ] # Nested arrays with an explicit key [ [ $foo ] => $bar ] # An array containing a closure Regards, -- Rowan Collins [IMSoP]
On Thu, Mar 14, 2019 at 3:49 PM Rowan Collins
email@example.com> wrote:> > Is it really that important to save two key strokes per closure? >I'd say that the (probably overwhelming) majority of arrow functions have a single parameter and, in those cases, the JS syntax saves four characters, ignoring whitespace. Another way of looking at it is that you have six characters of boilerplate with the fn() syntax versus two in JS (ignoring whitespace) for single param arrow functions.
On Thu, 14 Mar 2019 at 18:20, Josh Di Fabio <firstname.lastname@example.org> wrote:> On Thu, Mar 14, 2019 at 3:49 PM Rowan CollinsNo offense but at the end of the day having readable code is better than shorter code IMHO, so I don't really see the problem with having a couple of extra character/keystrokes as this is more readable then the massive boilerplate we currently have. However, I can see people beeing fond of the concise syntax of JS Best regards George P. Banyard
email@example.com> > wrote: > > > > Is it really that important to save two key strokes per closure? > > > > I'd say that the (probably overwhelming) majority of arrow functions > have a single parameter and, in those cases, the JS syntax saves four > characters, ignoring whitespace. Another way of looking at it is that > you have six characters of boilerplate with the fn() syntax versus two > in JS (ignoring whitespace) for single param arrow functions. >