[Accepted] SE-0279: Multiple Trailing Closures

[xwu (Xiaodi Wu)]

@John_McCall

However, Swift evolution is not a consensus process, or even a majoritarian one. The core team receives feedback that it disagrees with on essentially every single proposal, and it makes the decisions it makes anyway. You are welcome to disagree with those decisions, but that fact that you disagree does not mean that your feedback was ignored.

@John_McCall

I'm not disputing that there's a negative response to the decision. I'm saying that the negative response is chiefly because people want to be able to write a label on the first trailing closure (or to require it), not because there's a pervasive flaw in the process. People disagree with the decision.

The core team must take seriously that the response to this decision is not merely because of dissatisfaction with the specific result. It's dismissive to phrase it in those terms.

Here's a simple thought experiment:

• Mask out entirely the subject matter of proposal and the content of the replies.
• Present the following scenario to a member of the community: proposal SE-XXXX garnered nearly 400 replies on first review and was locked down; it was then revised and then re-reviewed, garnering nearly 200 replies on second review, then accepted without modification.
• What do you imagine the community member would predict as to the reaction to the review?

I have said this before, but I will say it again: the core team needs to be much more clear up-front in delineating what feedback is being solicited and under what constraints. During the first review, you stated on behalf of the core team:

SE-0279: Multiple Trailing Closures

The Core Team will definitely not accept a major redesign as a modification without further review.

What is implied by "further review" is what's at issue here. As evidenced by the 194 replies which that further review has received, the community took it to mean that we were actively engaging in the feature's redesign. The second review process would have gone differently--and would not have garnered 194 replies--if the core team had stated something to the following effect from the get-go:

• We have already determined that this is an important problem to be solved, and intend to implement some multiple trailing closure syntax.
• We intend this feature to be integrated into master by early May for inclusion in the next version of Swift.
• Based on feedback, we accept that an unbraced syntax has superior ergonomics to the braced version.
• After reviewing existing APIs, we have determined that the first argument label should be mandatorily omitted for reasons spelled out in the revised proposal.
• Our remaining questions for the community are: (1) Are there any unanticipated harms of the syntax as we propose which have not already been touched on in the proposal text or first review? (2) That's it; in your review, please keep in mind that the conclusions stated above are already decided.