- What is your evaluation of the proposal?
-1, for a few reasons, including:
- Tools should be fixed before changing the language. Xcode doesn't currently handle the completion of multiple closures at all, and suggests trailing closure syntax inconsistently, including after other closures. Fixing these issues, some of which was done as part of implementing this proposal, would go a long way to alleviate the ergonomic issues around multiple closures. Once those changes are in place a real evaluation of changing the language can happen.
- The proposed solution just doesn't work for many uses of multiple closures, and will have significant issues with existing code. Any code that doesn't have it's primary closure as the first parameter, or doesn't have a "primary" closure at all, will not work well with this design. So while SwiftUI's demos may look slick, I don't believe that will be the case for most APIs. We recently added a second closure parameter to one of Alamofire's APIs. It is actually secondary to the previous trailing closure, but this proposal would complete the two closures with the secondary one as primary, which would lead to poor API usage.
- The proposal, even if desired, offers library authors no control over the elided first parameter name, and imposes parsing rules on the reader that many users will not be familiar and may take time to learn. For proper integration into the Swift community, this proposal needs to offer customizations points, as it's solution is not one size fits all.
- Is the problem being addressed significant enough to warrant a change to Swift?
I don't believe so. Even if you accept the proposal's rationale, I don't believe it made the case that the problem described is severe enough to justify such a large change to the language. The tooling should be fixed and the problem reexamined.
- Does this proposal fit well with the feel and direction of Swift?
I don't believe so. Swift already has a reputation for arbitrary changes to language syntax in the name of sugar rather than tackling the real missing features and this proposal will just reinforce that idea. Given that we can get most of the benefit of this proposal by just improving the tooling, that approach should be explored before adding yet more syntax rules to the language.
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I don't think I've used other languages with a feature like this.
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
In depth read of both the current and previous proposals and participation in both review threads.