On Thu, 14 Mar 2019 at 15:10, Benjamin Morel <benjamin.mo...@gmail.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 <david.pro...@gmail.com> 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]
