On Sun, Mar 28, 2021, at 7:34 AM, Deleu wrote:
> >
> > but then we can bring up the side running RFC from
> > Larry which proposes to make the same short syntax available for other
> > function declarations, how would this work then with this mindset of
> > `fn` meaning auto capture? Does that mean a procedural function
> > declared with `fn` will now inherit the scope from which it was
> > declared (usually the global scope)? What about methods declarations,
> > do they import properties into the local scope? How does traits
> > interact here, same as methods?
> >
>
> I think I remember the 1st version of Larry's RFC proposing `public fn
> classMethod(): bool => $this->myAttr;` as a class method which seems to
> match what you're trying to say here, but that has been withdrawn and the
> RFC no longer proposes the fn keyword for class methods or function
> declarations, which is discussed under *Background* of RFC
> https://wiki.php.net/rfc/auto-capture-closure. Larry and Nuno may correct
> me if I'm wrong but as far as I understood, that change happened to address
> exactly the points you're describing here: what does `public fn
> classMethod(): bool` would capture? There's actually little to no reason to
> do it. Larry's RFC still proposes a great improvement for
> getters/setters/short methods and Nuno's RFC allows us to write code that
> is naturally expected to work, such as `fn () => {...}`.
>
> As for making `fn` an alias of `function` I believe that is already broken
> because of 7.4 arrow functions. As you describe, that would be "an
> exception" to PHP syntax, but more pressing it means that we would be
> wasting the potential of 2 separate keywords having different goals. I
> think it was Nikita that once said that we have a very limited budget on
> what we can do/offer through programming syntax and throwing `fn` out would
> be such a waste of that limited budget.
>
> --
> Marco Aurélio Deleu
The short-functions RFC as initially proposed had two variants, one which just
used =>, and one with used both => and fn. Personally I don't have that strong
of a feeling about function vs fn in that case. However, when discussing with
Nuno using "fn" to indicate auto-capture made the most sense, as => already
very clearly means "evaluates to expression."
I'm personally not wedded to any specific syntax, as long as the net result is
consistent and self-evident to both writers and readers, and allows for both
auto-capturing lambdas and expression-style functions.
I'm not wild about function and fn being universally synonymous. As Mike
notes, it would create another coding style battlefront of when you should use
one or the other since both are synonymous. What we'd likely end up with is
drifting toward the whole language using fn because it's easier to type, but
not everyone, so you'd have a lot of inconsistency between projects. If
function and fn mean different things, there is no room for subjective
preference. You use the keyword that means the behavior you want.
As a thought experiment, let's play with the "auto" keyword for a moment. (As
I'm typing this I don't know what it will produce.)
$c = 1;
// Existing syntax.
$f = function($a, $b) use ($c) {
return $a * $b * $c * $this->d;
};
// If you want to DISABLE object binding.
$d = $this->d;
$f = static function($a, $b) use ($c, $d) {
return $a * $b * $c * $d;
};
// If you want to ENABLE auto-capture.
$f = auto function($a, $b) {
return $a * $b * $c * $this->d;
};
// If you want to DISABLE object binding but ENABLE auto-capture.
$d = $this->d;
$f = static auto function($a, $b) {
return $a * $b * $c * $d;
};
So we end up with one enable toggle and one disable toggle. That's generally
considered a bad idea. It also means that what I believe is *usually* the most
common desired configuration (don't capture $this, but capture anything else)
the one that involves the most typing.
That doesn't seem ideal.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
