On Sat, Jun 11, 2022, at 4:14 PM, Rowan Tommins wrote: > On 09/06/2022 17:34, Larry Garfield wrote: >> Last year, Nuno Maduro and I put together an RFC for combining the >> multi-line capabilities of long-closures with the auto-capture compactness >> of short-closures ... Arnaud Le Blanc has now picked up the flag with an >> improved implementation ... The RFC has therefore been overhauled >> accordingly and is now ready for consideration. >> >> https://wiki.php.net/rfc/auto-capture-closure > > > First of all, thanks to all three of you for the work on this. Although > I'm not quite convinced yet, I know a lot of people have expressed > desire for this feature over the years.
> To go back to the point about variable scope: right now, if you're in a > function, all variables are scoped to that function. With a tiny handful > of exceptions (e.g. superglobals), access to variables from any other > scope is always explicit - via parameters, "global", "use", "$this", and > so on. If we think that should change, we should make that decision > explicitly, not treat it as a side-effect of syntax. > > I don't find the comparison to a foreach loop very convincing. Loops are > still only accessing variables while the function is running, not saving > them to be used at some indeterminate later time. And users don't "learn > to recognize" that a loop doesn't hide all variables from the parent > scope; it would be very peculiar if it did. There are languages that do, however. Some languages have block-scoped variables by default (such as Rust), or partially blocked scoped depending on details. PHP is not one of them, but to someone coming from a language that does, PHP's way of doing things is just as weird and requires learning. The point here is that "which things create a scope and which don't" are not "intuitive" in any language. They're always language-idiomatic, and may or may not be internally consistent, which is the important part. PHP is fairly internally consistent: functions and classes create a scope, nothing else does. This RFC doesn't change that one way or another, so it's not really any harder to learn. Plus, as noted, the `fn` keyword becomes consistently the flag saying "auto-capture happens here, FYI", which is already the case as of 7.4. > Which leads me back to my constructive suggestion: let's introduce a > block scoping syntax (e.g. "let $foo;") as a useful feature in its own > right, before we introduce short closures. > > As proposed, users will need to have some idea of what "live variable > analysis" means, or add dummy assignments, if they want to be sure a > variable is actually local. With a block scoping keyword, they can mark > local variables explicitly, as they would in other languages. That may be a useful feature on its own, especially for longer loops. I'm definitely open to discussing that. I don't think that is a prerequisite for a nicer lambda syntax, however, as I don't think the confusion potential is anywhere near as large as you apparently fear it is. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
