On 06/05/2017 09:19 AM, Rasmus Schultz wrote:
Of the proposed options, I'd prefer the double fat-arrow ==>
However, I remain of the opinion that all of those syntaxes are
work-arounds to ambiguity concerns for cases that likely don't actually
occur in real-world codebases.
I don't understand the motivation to design or optimize based on some
theoretical concerns - I'd strongly prefer we do the obvious thing, which,
as I see it, would be to do what most languages do, e.g. the familiar fat
arrow => syntax.
If we're going to provide a closure feature that works more like what you'd
typically find in other languages, we should try to also make it look like
it does in most other languages.
It was said of the generics syntax that I proposed that it would have
ambiguity issues, that it would be impossible (or very difficult) to
implement, but someone actually went an implemented it. I'm generally a bit
skeptical of people who cry "impossible" before giving it their best effort.
Inventing unfamiliar syntax for familiar features should be a painful last
resort, if there is no other choice.
Just my opinion.
I'd love to have this feature, but I'd prefer we don't introduce anymore
"muck" if it's at all avoidable.
On Mon, Jun 5, 2017 at 3:10 PM, Björn Larsson <bjorn.x.lars...@telia.com>
wrote:
Den 2017-06-01 kl. 18:58, skrev Theodore Brown:
On Tuesday, May 30, 2017 at 12:58 PM, Levi Morrison wrote:
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
5.
[](params) => expr // binds no values
[=](params) => expr // binds by value
[&](params) => expr // binds by reference
3 > 4 > 1.
2 is not even worth considering and I'd almost prefer not having arrow
functions if their syntax is going to be that self-defeating.
I also see no reason to include both by-value and by-reference binding
Arrow functions are for trivially simple cases where the extra ceremony
of an anonymous function is a waste. If you need to do something
non-trivial, use a full-on anonymous function as we already support.
I want to reiterate that, from a user-POV, arrow functions are barely
functions. It's a case for applying an expression to a set. In most
cases I don't "think about it" as a function in the first place.
$y = 2;
array_map($arr, ($x)=> $x*$y);
While I know that implementation-wise $x * 2 gets wrapped into a
function, that's not really how I'm mentally thinking about it. I'm
thinking of it more like a single line in a foreach. In my head, it's
an expression, not a function. If I needed to be "thinking about it
like a function", I'd use a more function-esque syntax.
The extra complication of multiple binding styles to think about are
just that: extra complication. If I care, then I should be using an
anonymous function whose use() syntax already lets me control that case.
I wonder if "Arrow functions" is even a misleading name for the feature,
in terms of how it should be used.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
