The amended proposal was received more positively. Several reviewers who had opposed the original proposal were now unreservedly in favor. Others supported the new proposal overall but expressed a preference for also allowing an argument label on the first closure.
However, many reviewers continued to oppose the amended proposal. Some reviewers expressed their dislike of trailing closures overall, or disputed the need to allow multiple trailing closures. The core team continues to believe, as we stated at the start of the second review, that the underlying motivation for the proposal is sound and changes here are merited. Other reviewers disliked the specifics of the change or felt that it was not tenable without allowing an argument label on the first closure or without substantial changes to the model for type-checking calls with trailing closures.
The core team carefully considered the case for allowing an argument label on the first closure and came to the following conclusions:
- The core team is not entirely satisfied with the basic design of trailing closures in Swift today. The feature stands out as one of the few places in the language that leaves discretion about the appearance of the call site — and especially the use of a label — to the caller rather than the API author. If we were free to redesign the language without restrictions, we would likely do this feature differently.
- However, Swift is now an established language, and there are limits to what changes we can justify, even in a new source-compatibility version. A change that only allowed an unlabeled trailing closure to match an unlabeled parameter is very hard to imagine ever being acceptable. We are not ready to completely rule such a change out, but it would need a very strong source-compatibility and migration story.
- Because of this, the core team feels that these aspects of the single trailing closure design must be taken as given, and that it is better to design multiple trailing closures as a consistent extension of those rules, as SE-0279 proposes, rather than imagining that those rules can be fundamentally rewritten to accommodate a generalization.
The core team agree with the proposal's suggestion that the API guidelines be amended to recommend naming functions "assuming that the argument label of the first trailing closure will be dropped".