On Tue, 6 Oct 2020 at 12:20, Brent Roose <bre...@stitcher.io> wrote: > The point of short closures, regardless of single line or multi line, is > addressed (and agreed upon by the RFC votes) in the first pararaph of the > RFC [1]. I'm not sure if I can add anything useful rather than saying "it's > nice to be able to write more consise code. It feels a little more smooth". >
The thing is, the RFC voters have agreed on single-*expression*, there is a high likelihood that if multi-line (i.e. multiple statements/expression) support was included in this RFC it would have failed. Why do I think this? Look at the previous vote: https://wiki.php.net/rfc/short_closures So your conclusion about what the voters agreed is completely nonsensical here. > There's actually one more argument to be made: they would make the use of > closures more consistent for those of who _prefer_ short closures. Now > you're forced to mix up both the short and long syntax. As an example, I > use Laravel's collections [2] which provide a functional API to interact > with lists of data. You often chain these calls, and are able to use short > closures like 80% of the time, but sometimes you're forced to use the > longer syntax. > > So that's my two arguments for multi-line closures > > - Making code less verbose, which is the _same_ goal of single-line short > closures, which was accepted by the vast majority of PHP > - Consistency with already existing single-line short closures > Ignoring the first point, refer back to the previous paragraph. What consistency is there if there is no implicit return in the block form? Sure it is annoying that for a 2-liner, where you probably won't "forget" about the fact that you are importing the outer scope it is annoying that you need to go the longer route. But that's not a sufficient argument IMHO. > My point is that PHP is evolving towards a modern language, and with that > come syntax changes that not everyone likes or wants to use. @ for > attributes isn't chosen because it simply isn't possible to support that > syntax, not because of what the community _and_ internals want or don't > want. I don't think of this as a counter argument to my original point: PHP > has seen a significant increase in syntax sugar additions over the past few > years. If no one wanted those, they woulnd't have been voted in. Would you > like to address that argument? Why are promoted properties, single-line > short closures, named argument, etc added besides that there's a "want" for > them? > The core difference here is that it doesn't change a *fundamental* aspect of the language (or in the case of single-expression closure it changes 3 aspects making them very special), you might not like this aspect but it is still present. Obviously nothing is necessary, we could write assembler style with only goto statements. That's exactly what I'm saying! It's ok to add syntax to make a developer's > life easier. There are cases where that's a good enough argument. > And this is not one of them, at least for me, and I don't think I'm alone here. > Why was auto capture added to single line short closures last year? We've > had this discussion before, and the majority of internals voted "yes" back > then. So instead of only re-iterating the same discussion, why not provide > Nuno with useful feedback as well? > And once *again* short-closure don't *just* have the auto-import of the outer scope going for it. The other main features of the short closure are not applicable to a block syntax. - the fact that there is an implicit return - it is a single expression, *no* braces therefore it doesn't look like it creates a new scope. You ignoring these facets which are key benefits which only apply to the short closure case, to imply the extension to multi-line is a "no-brainer" is not making a case for it. My opinion is already that the way PHP does closures is the Sane Way To Do It TM, you have a dependency on a variable therefore you need to specify it, is IMHO a good thing. Do other languages function just fine with the opposite behaviour, sure. At the same time Java has implicit nullable type arguments and people deal with it. Best regards George P. Banyard
