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 a problem with this.
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 an
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 solves the ambiguity pr
> 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 that the fn keyword solv
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 namesp
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 is
