Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99282
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Tue, 30 May 2017 20:40:19 +0100 (BST)
To: Levi Morrison <levim@php.net>
cc: internals <internals@lists.php.net>
In-Reply-To: <CAFMT4Npoo_ZrRk-kk4C6KHYEtV93pU7Wmh0FhaPi6Z-9qkObaQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1705302038520.2232@singlemalt.home.derickrethans.nl>
References: <CAFMT4Npoo_ZrRk-kk4C6KHYEtV93pU7Wmh0FhaPi6Z-9qkObaQ@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Subject: Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
From: derick@php.net (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 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) => expr
> 
>   3. (params) ==> expr
>   4. (params) => expr
> 
> Note that 3 and 4 require a more powerful grammar and parser and that
> 4 has ambiguities. I think we can work around them by rules -- only
> mentioning it because its popular because of JavaScript and do not
> prefer this at all.
> 
> Note that 1 requires a new keyword.
> 
> Option 2 looks the best from that perspective but is by far the
> longest; remember people are partially interested in this feature
> because they want shorter closures which this doesn't really help.
> 
> This is why everyone is so divisive. All options have drawbacks.
> Additionally some people don't like binding by value and would prefer
> ref, and others really would be against by-ref.
> 
> Which brings me to an option I don't think was ever discussed on list:
> 
>   5.
>      [](params) => expr     // binds no values
>      [=](params) => expr    // binds by value
>      [&](params) => expr    // binds by reference
> 
> It has quite a few good qualities:
> 
>   - No new keywords
>   - Can choose between reference and value
>   - Concise
>   - Has precedence in C++, a major language
>   - Can be done in our existing grammar and parser[1]
>   - Can be extended to allow explicit binding of variables:
>       // all equivalent
>       // y is bound by value, array by reference
>       [&, $y]($x) => $array[] = $x + $y
>       [=, &$array]($x) => $array[] = $x + $y
> 
> And of course it does have downsides:
> 
>   - Symbol soup (it uses a lot of symbols)
>   - A minor BC break. Empty arrays which are invoked as functions are
> currently guaranteed to be errors at runtime and would have a new
> valid meaning. Here's an example from inside an array literal:
> 
>       // error at runtime previously
>       [ []($x) => $x ]
>       // now an array with one item which is a closure that returns
> its parameter
> 
> Sara pointed out that we'd need to keep a leading `=` or `&` in the
> array to disambiguate from our array closure form.
> 
> Overall I'd prefer 1 or 5. What do you guys think?

I think 5 is terrible from a readability point of view. As you said it: 
"symbol soup".

For a similar reason, I would discount 1 as being too vague. And hence 
would prefer 2, but I'm not actually convinced about this feature at 
all.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php
twitter: @derickr and @xdebug