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

On Thu, Jun 9, 2022 at 9:39 PM Marco Pivetta <ocramius@gmail.com> wrote: > Hey Nikita, > > On Thu, 9 Jun 2022 at 21:35, Nikita Popov <nikita.ppv@gmail.com> wrote: > >> On Thu, Jun 9, 2022 at 9:29 PM Marco Pivetta <ocramius@gmail.com> wrote: >> >>> >>> On Thu, 9 Jun 2022 at 21:27, Nikita Popov <nikita.ppv@gmail.com> wrote: >>> >>>> On Thu, Jun 9, 2022 at 8:15 PM Arnaud Le Blanc <arnaud.lb@gmail.com> >>>> wrote: >>>> >>>>> > Would that allow us to get rid of static fn () >>>>> > { declarations, when >>>>> > creating one of these closures in an instance method context? >>>>> >>>>> It would be great to get rid of this, but ideally this would apply to >>>>> Arrow >>>>> Functions and Anonymous Functions as well. This could be a separate >>>>> RFC. >>>>> >>>> >>>> I've tried this in the past, and this is not possible due to implicit >>>> $this uses. See >>>> >>>> https://wiki.php.net/rfc/arrow_functions_v2#this_binding_and_static_arrow_functions >>>> for a brief note on this. The tl;dr is that if your closure does "fn() => >>>> Foo::bar()" and Foo happens to be a parent of your current scope and bar() >>>> a non-static method, then this performs a scoped instance call that >>>> inherits $this. Not binding $this here would result in an Error exception, >>>> but the compiler doesn't have any way to know that $this needs to be bound. >>>> >>>> Regards, >>>> Nikita >>>> >>> >>> Hey Nikita, >>> >>> Do you have another example? Calling instance methods statically is... >>> well... deserving a hard crash :| >>> >> >> Maybe easier to understand if you replace Foo::bar() with parent::bar()? >> That's the most common spelling for this type of call. >> >> I agree that the syntax we use for this is unfortunate (because it is >> syntactically indistinguishable from a static method call, which it is >> *not*), but that's what we have right now, and we can hardly just stop >> supporting it. >> > > Dunno, it's a new construct, so perhaps we could do something about it. > I'm not suggesting we change the existing fn or > function declarations, > but in this case, we're introducing a new construct, and some work already > went in to do the eager discovery of by-val variables. > > Heck, variable variables already wouldn't work here, according to this RFC > :D > We're not introducing a new construct. We're just extending existing fn() functions to accept {} blocks, with exactly the same semantics as before. I would find it highly concerning if fn() => X and fn() => { return X; } had differences in capture semantics. Those two expressions should be strictly identical -- the former should be desugared to the latter. Nikita