Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105312
User-Agent: Cyrus-JMAP/3.1.6-443-g918f9d3-fmstable-20190416v3
Mime-Version: 1.0
Message-ID: <3b6337b3-7a0c-470c-b648-7e04866f7833@www.fastmail.com>
In-Reply-To: 
 <CAF+90c8yJkuJYuRZZrbnJ1rv7xOv+zUuevP9B+fpok960VQxcw@mail.gmail.com>
References: 
 <CAF+90c9YZcrquGfS4h3x1a+codkCFLarAThsOXcN69RCTvbAFA@mail.gmail.com>
 <CAF+90c_keZTbMTuDO+9WRa53MsYxbNxkMO_pxGyymGnxCp691g@mail.gmail.com>
 <CAF+90c8yJkuJYuRZZrbnJ1rv7xOv+zUuevP9B+fpok960VQxcw@mail.gmail.com>
Date: Wed, 17 Apr 2019 10:14:47 -0400
To: internals@lists.php.net
Content-Type: text/plain
Subject: Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Apr 14, 2019, at 11:52 AM, Nikita Popov wrote:

> So, there's been quite a bit of extra discussion here... unfortunately I
> can't say that it really clarified anything, we're still circling around
> different syntax choices, with the main contenders being fn, \ and ==>.
> 
> fn($x) => $x
> fn($x, $y) => $x*$y
> 
> \$x => $x
> \($x, $y) => $x*$y
> 
> $x ==> $x
> ($x, $y) ==> $x*$y
> 
> I think the main qualities of these possibilities are:
> 
>  * Implementation complexity: fn and \ are easy, ==> is hard (lexer hack).
>  * Availability of reduced syntax: \ an ==> have a special single-argument
> syntax, fn doesn't.
>  * Obviousness/readability: fn and ==> are obvious, while \ is not.
> Especially \$x => $x looks quite obscure to the uninitiated (is that a
> variable escape, like it would be in strings?)
> 
> At this point I'm considering to either a) move forward with fn() as the
> choice I'd consider most likely to gather a consensus or b) have a
> secondary three-way vote between these three syntax choices.
> 
> Nikita

I was under the impression from your earlier comments that ==> made the lexer too unhappy to even consider.  Is that not the case?

From a usability POV, I think ==> has the edge; it's reasonably self-documenting and has a short-circuit version that is still highly readable and not confusing.  It also fits the "think of it as an expression not a function call" mindset, which is important.  The only downside is the implementation complexity.  I think you have final call on whether that would be too-ugly implementation-wise.

If it doesn't make the lexer too unhappy ==> is my preference, I think.  \$x I'd probably get used to, even if it is a bit ugly.  fn() is the "safe" option: Most verbose but keeps the lexer happy.

--Larry Garfield