The Goal
My goal for Swift has always been and still is total world domination. It’s a modest goal. -- Chris Lattner, June 30, 2017
An Important Part of the Path to the Goal
Swift 3 pivoted about halfway through: the main goal changed from ABI stability to source stability. And I think that was totally the right thing to do. … What we realized halfway through the Swift 3 development cycle was, as the community is growing and as more and more people are writing more and more code, not breaking that code became really important. … One of the reasons we started out by saying that Swift is not source-stable is that we knew that before the open-source release we didn’t have the benefit of lots of people debating, discussing, arguing, and bikeshedding. And you really need that to make something great. -- Chris Lattner, June 30, 2017
How People Pick a Programming Language
Everyday, people make decisions about which programming language to use for a project. They consider many factors, including backward compatibility.
For people that manage money, backward compatibility of a programming language is important because it lowers the cost of maintenance in the near to middle term.
For people that manage risk, backward compatibility of a programming language is important because it reduces the chances of real world harm and financial losses caused by bugs that come with new versions and migration.
For people that manage enterprise-scale products, backward compatibility of a programming language is important because it reduces the frequency of updates and disruptions for their customers.
...and so on...
Nearly all of the people making those decisions care not one whit about whether a trailing closure is labelled. They would be very upset by the notion that requiring a label on a trailing closure might put their budgets, their missions, their products and their customers at risk of migration bugs. They would think of Swift as being risky or unreliable.
So, we need to work very, very hard to find creative and brilliant ways to improve what we have without breaking what they have. Otherwise, those people won't allow Swift to be used for their projects, and Swift won't make the leap to wide-spread adoption.
The Core Team Has No Choice
And, like it or not, that is why the Core Team must take such a firm stance against breaking changes. I would imagine that the Core Team, in their heart of hearts, want to make changes and to make Swift shine even brighter than it does already. But, they are responsible stewards, and will do what needs to be done to achieve the goal. We should applaud them.