Re: [RFC] Short Closures 2, aka auto-capture take 3

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