-0.5
I like this much better than the first version, and I think I could come to terms with it, although the confusing way this interacts with default arguments seems like it would be annoying to library authors who'd have to jump in and add additional overloads to make their APIs usable, and confusing to users who don't understand the quite complex rules. And that will remain until we get a chance to fix it in a new language mode, whenever that will come to pass.
Overall though, I don't think this goes far enough to be worth it, and I think there are two directions which I would like to see explored:
-
Apply the proposed syntax to all arguments:
I think it is beneficial to break out long closures without having them surrounded by punctuation, but I believe the same thing applies to longer normal parameters (e.g. a call to an initializer with multiple arguments, which is itself broken into multiple lines), or just a large number of smaller parameters. Maybe allow omitting the comma in multi-line argument lists while we're at it.
This would end up similar to one of the more "crazy" examples of what Chris described in the first review thread, which looks quite good to me.
-
Have a special syntax for closures, but make it feel like building syntax:
This would be different enough to warrant a completely new proposal, and is a bit more out there, but if we do want special syntax for closures alone, I'd much rather we expand on the precedent of allowing library-authors to build syntax-like constructs, which would mean dropping the
:and allowing some way to pass parameters to the "labels" of closures after the first one (which would of course really be passed to the original function invocation).I guess—but do now know for certain—this should be parseable, as it is just like saying "there is this other function that takes a trailing closure, but you are only allowed to call it right after calling the original function". Please correct me if I'm wrong on this though :)
In its current form, barely. I don't think having to wrap the whole parameter list, including closures, in () and maybe dropping in a few line-breaks is all too bad for either readability or writability. Omitting those is quite nice from an aesthetic standpoint, but I don't think it's worth it if we're just special-casing closures in a weird way.
Not in my eyes, as I really like the concept of defining syntax-like constructs in library code, and this moves trailing closures away from that direction. If this was just a general thing you could do with argument lists, I'd be okay with it, but as is I don't think it makes sense.
Ruby allows omitting parens around argument lists, and I like that feature very much. Other than that no.
I read both versions of the proposal and loosely followed both review threads, but I've not done that deep a dive on it.