There is never a better time to make a breaking change than right now.
Why does make treat tabs and spaces differently? Because Feldman's original version had that bugs and he didn't want to disrupt the <10 users and their <100 makefiles. That was the wrong decision, though he didn't know it at the time.
However many users Swift has today, tomorrow there will be more. However many lines of code are written in it, tomorrow there will be more. The pain of making a change will only increase.
Apple was up front with everyone about Swift 1: there will be source-breaking changes in the future. Swift 3 was targeting source stability so it was the last chance to make such large changes.
In contrast, Swift 3.2 and Swift 4.0 are compiled by the same compiler and can be linked together. That means you can upgrade each module separately and don't have to wait for dependencies to upgrade. That's a huge win.
Swift 4 also brings Codable which will shave a massive amount of boilerplate from many codebases. The String overhaul is great too, along with generics improvements. These all affect the standard library and thus ABI stability.
The Law of Exclusivity is in, which is the core of the upcoming memory ownership model, which itself will enable async and other concurrency paradigms. This also affects ABI.
Once ABI stability lands the pace of standard library changes will necessarily slow dramatically. It is important to take the time to get things right, rather than rushing and locking bad or insufficient designs into stone.
Why does make treat tabs and spaces differently? Because Feldman's original version had that bugs and he didn't want to disrupt the <10 users and their <100 makefiles. That was the wrong decision, though he didn't know it at the time.
However many users Swift has today, tomorrow there will be more. However many lines of code are written in it, tomorrow there will be more. The pain of making a change will only increase.
Apple was up front with everyone about Swift 1: there will be source-breaking changes in the future. Swift 3 was targeting source stability so it was the last chance to make such large changes.
In contrast, Swift 3.2 and Swift 4.0 are compiled by the same compiler and can be linked together. That means you can upgrade each module separately and don't have to wait for dependencies to upgrade. That's a huge win.
Swift 4 also brings Codable which will shave a massive amount of boilerplate from many codebases. The String overhaul is great too, along with generics improvements. These all affect the standard library and thus ABI stability.
The Law of Exclusivity is in, which is the core of the upcoming memory ownership model, which itself will enable async and other concurrency paradigms. This also affects ABI.
Once ABI stability lands the pace of standard library changes will necessarily slow dramatically. It is important to take the time to get things right, rather than rushing and locking bad or insufficient designs into stone.