On Fri, Mar 15, 2019 at 10:31 AM Rowan Collins <[email protected]> wrote:
> On Fri, 15 Mar 2019 at 09:01, Alexandru Pătrănescu <[email protected]> > wrote: > > > My question would be: whatever syntax we are going to use that has arrow > > syntax, let's say *$f = \($x) => $x * 2;* are we going to also support > the > > arrow block version?: > > *$f = \($x) => {* > > * // more operations that will have better visible on multi-line* > > > > * return $x * 2;* > > *}* > > > > > See "Future Scope" in the RFC: > > > This feature is omitted in this RFC, because the value-proposition of > this syntax is much smaller: Once you have multiple statements, the > relative overhead of the conventional closure syntax becomes small. > > We shouldn't pick a syntax that rules it out, but it can be added later, > with a separate RFC to discuss the benefits and details. > It might be worth giving some consideration to the possibility of introducing this syntax already in this RFC. The main problem with punting this off for later is that it may be necessary to refactor closures between the short and the long form regularly: You need an extra statement in the closure? You have to switch closure types, and also not forget to write our the use() list this time. On the other hand, allowing a block body for the closure does add a number of complications to this proposal: 1. Syntax choice. Given the fn() syntax, we could go for either fn() {} or fn() => {}. 2. By-ref binding: While by-reference binding is not useful for single-expression closures, there will be cases where it's needed for block closures. We will also need to choose a syntax to opt-in to by-reference binding. The RFC suggests use(&), which is somewhat non-great. 3. Determining bound variables. For single-expression closures we can get away with binding all variables that are used inside the closure. Writing something like fn() $a = $b might cause an unnecessary binding of $a, but it's also a very contrived situation. For block closures performing assignments inside the closure will be much more common and will need some more consideration to avoid unnecessary bindings. Regards, Nikita
