# Winding down the Swift 3 release **URL:** \ **Category:** Discussion\ **Created:** [May 16, 2016, 3:18pm UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631 "2016-05-16T15:18:27Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![Pierre\_Habouzit](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/pierre_habouzit/32/11012_2.png) [@Pierre\_Habouzit](https://forums.swift.org/u/Pierre_Habouzit)\ **Post date:** [May 17, 2016, 3:00pm UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/21 "2016-05-17T15:00:20Z")
> > Quite sad we could not get into ABI stability for Swift 3... but are we talking Swift 3.1 or 4.0? > > Disappointing is my first thought, in fact worrying. Two years after the language was announced, the ABI is still not stable. > > Of the original Swift 3 goals, it looks like many will not be met. There were seven goals and only two are still in the Readme file[1]. On the assumption that the other five were all dropped because they will not be achieved in Swift 3, this looks like failure. > > I’ve been following the evolution list on and off since it started and it hasn’t felt like failure. In fact, it felt like important progress has been made and the language will be hugely better for it, but I do hope that the development team does take the opportunity to review the release in light of the original goals to see if there are any opportunities to improve the development process for the next release. > **[Hofstadter's law](https://en.wikipedia.org/wiki/Hofstadter%27s_law)** > > Hofstadter's law is a self-referential adage, coined by Douglas Hofstadter in his book Gödel, Escher, Bach: An Eternal Golden Braid (1979) to describe the widely experienced difficulty of accurately estimating the time it will take to complete tasks of substantial complexity: > Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. The law is often cited by programmers in discussions of techniques to improve productivity, such as The Mythical Ma... > [1] [https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md](https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md) compared to [https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md](https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md) -Pierre > **···** > > > On May 17, 2016, at 5:35 AM, Jeremy Pereira via swift-evolution \ wrote: > > > > > On 16 May 2016, at 18:38, Goffredo Marocchi via swift-evolution \ wrote: ---
**Author:** ![Rod\_Brown](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/rod_brown/32/425_2.png) [@Rod\_Brown](https://forums.swift.org/u/Rod_Brown)\ **Post date:** [May 17, 2016, 1:38pm UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/22 "2016-05-17T13:38:11Z")
While on the face of it, you are correct, the goals have changed dramatically, I think you are being unfair. Swift 3 initial scope was determined prior to the input of the Swift Evolution community, just as it was being Open Sourced. As we have explored the language in many discussions, it has been clear there are other areas of the language that needed clean and polish before a stable ABI can be established. It appears that this work is more involved than the Swift Team initially envisioned. The fact they are open to changing timelines and ensuring we get fundamentals of the language sorted is a testament to their commitment to the quality of Swift as a whole. Looking at Swift 3 as compared to Swift 2, there are massive changes in the pipeline that both break source and change the language fundamentally. I think it's far too much to ask that they get this work done rushed, and also pile on ABI compatibility goals at the last minute. Do we really want to rush this and get it wrong? I applaud the team in making a tough decision that these changes should come before we start working on the ABI. - Rod > **···** > > > On 17 May 2016, at 10:35 PM, Jeremy Pereira via swift-evolution \ wrote: > > > > > On 16 May 2016, at 18:38, Goffredo Marocchi via swift-evolution \ wrote: > > > > > > Quite sad we could not get into ABI stability for Swift 3... but are we talking Swift 3.1 or 4.0? > > > > Disappointing is my first thought, in fact worrying. Two years after the language was announced, the ABI is still not stable. > > > > Of the original Swift 3 goals, it looks like many will not be met. There were seven goals and only two are still in the Readme file[1]. On the assumption that the other five were all dropped because they will not be achieved in Swift 3, this looks like failure. > > > > I’ve been following the evolution list on and off since it started and it hasn’t felt like failure. In fact, it felt like important progress has been made and the language will be hugely better for it, but I do hope that the development team does take the opportunity to review the release in light of the original goals to see if there are any opportunities to improve the development process for the next release. > > > > [1] [https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md](https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md) compared to [https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md](https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md) > > > > > Sent from my iPhone > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![dwaite](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dwaite/32/1200_2.png) [@dwaite](https://forums.swift.org/u/dwaite)\ **Post date:** [May 17, 2016, 6:37pm UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/23 "2016-05-17T18:37:27Z")
With semantic versioning, the API changes would require the next version to be called 3.0. The challenge is to not attach stability/maturity ‘feelings’ to semantic version numbers. I don’t think people should attach meaning to Swift being 3.0 any more than they do to Chrome being 50.0 If we insist 3.0 is not just a sign of an incompatible API but a sign of maturity, then we will have no releases until the “maturity” feature-set gets in. Which means we will lose a great deal of real world use and feedback into language design and evolution. -DW > **···** > > > On May 17, 2016, at 12:05 PM, Goffredo Marocchi via swift-evolution \ wrote: > > > > I do agree with what you are saying, but in a way it seems to also be saying that the version number set by Apple is a bit rushed. A language reaching 3.0 state and not having nailed down ABI stability sounds a lot different than Swift 0.95 or Swift 1.5 being at the same state and I do not think it would say anything bad about the language if it only hit 1.0 when it reaches ABI stability. > > > > It would be sad if the argument were "people would not use Swift if it were still v0.9" as it brings back memories of the KDE 4.0 jump (Swift is nowhere near the unstable mess KDE 4.0 was, but they had that very same justification for using the 4.0 version number). > > > > Sent from my iPhone > > > > > On 17 May 2016, at 14:38, Rod Brown \ wrote: > > > > > > While on the face of it, you are correct, the goals have changed dramatically, I think you are being unfair. > > > > > > Swift 3 initial scope was determined prior to the input of the Swift Evolution community, just as it was being Open Sourced. As we have explored the language in many discussions, it has been clear there are other areas of the language that needed clean and polish before a stable ABI can be established. > > > > > > It appears that this work is more involved than the Swift Team initially envisioned. The fact they are open to changing timelines and ensuring we get fundamentals of the language sorted is a testament to their commitment to the quality of Swift as a whole. > > > > > > Looking at Swift 3 as compared to Swift 2, there are massive changes in the pipeline that both break source and change the language fundamentally. I think it's far too much to ask that they get this work done rushed, and also pile on ABI compatibility goals at the last minute. Do we really want to rush this and get it wrong? > > > > > > I applaud the team in making a tough decision that these changes should come before we start working on the ABI. > > > > > > - Rod > > > > > > > On 17 May 2016, at 10:35 PM, Jeremy Pereira via swift-evolution \ wrote: > > > > > > > > > On 16 May 2016, at 18:38, Goffredo Marocchi via swift-evolution \ wrote: > > > > > > > > > > Quite sad we could not get into ABI stability for Swift 3... but are we talking Swift 3.1 or 4.0? > > > > > > > > Disappointing is my first thought, in fact worrying. Two years after the language was announced, the ABI is still not stable. > > > > > > > > Of the original Swift 3 goals, it looks like many will not be met. There were seven goals and only two are still in the Readme file[1]. On the assumption that the other five were all dropped because they will not be achieved in Swift 3, this looks like failure. > > > > > > > > I’ve been following the evolution list on and off since it started and it hasn’t felt like failure. In fact, it felt like important progress has been made and the language will be hugely better for it, but I do hope that the development team does take the opportunity to review the release in light of the original goals to see if there are any opportunities to improve the development process for the next release. > > > > > > > > [1] [https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md](https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md) compared to [https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md](https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md) > > > > > > > > > Sent from my iPhone > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Eric\_Wing](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/eric_wing/32/3548_2.png) [@Eric\_Wing](https://forums.swift.org/u/Eric_Wing)\ **Post date:** [May 17, 2016, 10:45pm UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/24 "2016-05-17T22:45:53Z")
So I don’t mind (too much) if it takes longer to get a stable ABI. It makes my life harder, but on the flip-side, I don’t want to be stuck with yet another broken language and ABI. I want this done right because it will be almost impossible to fix later. Here’s a simple, yet tragic example: BOOL in Objective-C. We were stuck with signed char instead of getting a real boolean. Back in 10.4 Tiger when the Intel migration was announced, I filed a bug report reminding them that this was the chance to fix this. They didn’t fix it, so we were stuck. Then I filed again in the 10.5 beta Leopard time frame during the 64-bit transition, I filed again reminding them that this should be fixed before the 64-bit ABI gets locked down. Again, it wasn’t fixed so we were stuck. Then when the iOS SDK was going to become public, I filed again. Still not fixed. Then armv7, still nothing. Finally, for arm64, this was finally fixed. Too bad we’re stuck on Mac with this probably forever. Anyway, I don’t want to deal with another monstrous broken language. We have enough of those already. I actually consider it a good sign when languages remove features instead of add them even if it causes some migration pain. And I appreciate caution about making sure things are correct and good before locking down an ABI we’re probably going to be stuck with for at least another decade. I assume that Apple still understands the importance of ABI compatibility due to the Mac heritage and now that iOS has enabled 3rd party framework support. So I’m fairly confident they will eventually nail down a stable ABI. I just don’t want the Swift team to forget that a stable ABI is important for all the other platforms too (even if those platforms are terrible at delivering this themselves). Thanks, Eric ---
**Author:** ![trs](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/trs/32/2038_2.png) [@trs](https://forums.swift.org/u/trs)\ **Post date:** [May 17, 2016, 2:55pm UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/25 "2016-05-17T14:55:47Z")
+1 -Thorsten > **···** > > > Am 17.05.2016 um 15:38 schrieb Rod Brown via swift-evolution \: > > > > While on the face of it, you are correct, the goals have changed dramatically, I think you are being unfair. > > > > Swift 3 initial scope was determined prior to the input of the Swift Evolution community, just as it was being Open Sourced. As we have explored the language in many discussions, it has been clear there are other areas of the language that needed clean and polish before a stable ABI can be established. > > > > It appears that this work is more involved than the Swift Team initially envisioned. The fact they are open to changing timelines and ensuring we get fundamentals of the language sorted is a testament to their commitment to the quality of Swift as a whole. > > > > Looking at Swift 3 as compared to Swift 2, there are massive changes in the pipeline that both break source and change the language fundamentally. I think it's far too much to ask that they get this work done rushed, and also pile on ABI compatibility goals at the last minute. Do we really want to rush this and get it wrong? > > > > I applaud the team in making a tough decision that these changes should come before we start working on the ABI. > > > > - Rod > > > > > On 17 May 2016, at 10:35 PM, Jeremy Pereira via swift-evolution \ wrote: > > > > > > > On 16 May 2016, at 18:38, Goffredo Marocchi via swift-evolution \ wrote: > > > > > > > > Quite sad we could not get into ABI stability for Swift 3... but are we talking Swift 3.1 or 4.0? > > > > > > Disappointing is my first thought, in fact worrying. Two years after the language was announced, the ABI is still not stable. > > > > > > Of the original Swift 3 goals, it looks like many will not be met. There were seven goals and only two are still in the Readme file[1]. On the assumption that the other five were all dropped because they will not be achieved in Swift 3, this looks like failure. > > > > > > I’ve been following the evolution list on and off since it started and it hasn’t felt like failure. In fact, it felt like important progress has been made and the language will be hugely better for it, but I do hope that the development team does take the opportunity to review the release in light of the original goals to see if there are any opportunities to improve the development process for the next release. > > > > > > [1] [https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md](https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md) compared to [https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md](https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md) > > > > > > > Sent from my iPhone > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![gparker42](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gparker42/32/373_2.png) [@gparker42](https://forums.swift.org/u/gparker42)\ **Post date:** [May 18, 2016, 12:33am UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/26 "2016-05-18T00:33:18Z")
We apologize for the inconvenience. The OS X and iOS architecture transitions demonstrate the two fundamental laws of ABI changes: 1. Opportunities to break ABI compatibility are rare. 2. Any opportunity to break ABI compatibility will suffer from severe schedule pressure. The Objective-C ABIs have many problems that would have been improved with more time. \* We tried to get a "modern" ABI into i386, but the schedule was too tight and we lost time with some initial design ideas that didn't pan out. x86\_64 was also a tight schedule, but much of the work was already in place from the i386 attempt so we were able to get it done. \* Fixing BOOL was repeatedly not quite high enough priority. \* The 64-bit metadata structures have at least one field that is 64-bit by accident (protocol\_list\_t.count). There was miscommunication between the compiler and the runtime when the design was specified, and then it was never high enough priority to coordinate a fix later. \* armv7 uses setjmp-longjmp exceptions instead of "zero-cost" exceptions because that's what GCC's arm compiler used then and we didn't have time to change it. \* The very first iPhone did not use a "modern" ABI. We knew we could break ABI compatibility at any time before 3rd party apps were supported, so we punted ABI modernization until after 1.0. \* Non-fragile ivars on iPhone had a fragility bug in the compiler. (You don't see non-fragile ivars doing their thing until the \*second\* release, except for deliberate testing. We didn't test enough.) Luckily the bad case was narrow and the miscompiled code was detectable by inspecting binaries in the App Store, so we were able to ask all of the affected apps to recompile with a fixed compiler before the next iPhoneOS version shipped. If we tried to rush Swift ABI stability out the door for Swift 3 we would certainly end up with deliberate or accidental flaws like the above. Being able to take the time to get it right is a rare luxury. > **···** > > > On May 17, 2016, at 3:45 PM, Eric Wing via swift-evolution \ wrote: > > > > So I don’t mind (too much) if it takes longer to get a stable ABI. It > > makes my life harder, but on the flip-side, I don’t want to be stuck > > with yet another broken language and ABI. I want this done right > > because it will be almost impossible to fix later. > > > > Here’s a simple, yet tragic example: BOOL in Objective-C. We were > > stuck with signed char instead of getting a real boolean. Back in 10.4 > > Tiger when the Intel migration was announced, I filed a bug report > > reminding them that this was the chance to fix this. They didn’t fix > > it, so we were stuck. Then I filed again in the 10.5 beta Leopard time > > frame during the 64-bit transition, I filed again reminding them that > > this should be fixed before the 64-bit ABI gets locked down. Again, it > > wasn’t fixed so we were stuck. Then when the iOS SDK was going to > > become public, I filed again. Still not fixed. Then armv7, still > > nothing. Finally, for arm64, this was finally fixed. Too bad we’re > > stuck on Mac with this probably forever. > > -- > Greg Parker gparker@apple.com \ Runtime Wrangler ---
**Author:** ![Panajev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/panajev/32/1227_2.png) [@Panajev](https://forums.swift.org/u/Panajev)\ **Post date:** [May 17, 2016, 6:05pm UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/27 "2016-05-17T18:05:36Z")
I do agree with what you are saying, but in a way it seems to also be saying that the version number set by Apple is a bit rushed. A language reaching 3.0 state and not having nailed down ABI stability sounds a lot different than Swift 0.95 or Swift 1.5 being at the same state and I do not think it would say anything bad about the language if it only hit 1.0 when it reaches ABI stability. It would be sad if the argument were "people would not use Swift if it were still v0.9" as it brings back memories of the KDE 4.0 jump (Swift is nowhere near the unstable mess KDE 4.0 was, but they had that very same justification for using the 4.0 version number). > **···** > > Sent from my iPhone > > > On 17 May 2016, at 14:38, Rod Brown \ wrote: > > > > While on the face of it, you are correct, the goals have changed dramatically, I think you are being unfair. > > > > Swift 3 initial scope was determined prior to the input of the Swift Evolution community, just as it was being Open Sourced. As we have explored the language in many discussions, it has been clear there are other areas of the language that needed clean and polish before a stable ABI can be established. > > > > It appears that this work is more involved than the Swift Team initially envisioned. The fact they are open to changing timelines and ensuring we get fundamentals of the language sorted is a testament to their commitment to the quality of Swift as a whole. > > > > Looking at Swift 3 as compared to Swift 2, there are massive changes in the pipeline that both break source and change the language fundamentally. I think it's far too much to ask that they get this work done rushed, and also pile on ABI compatibility goals at the last minute. Do we really want to rush this and get it wrong? > > > > I applaud the team in making a tough decision that these changes should come before we start working on the ABI. > > > > - Rod > > > > > On 17 May 2016, at 10:35 PM, Jeremy Pereira via swift-evolution \ wrote: > > > > > > > On 16 May 2016, at 18:38, Goffredo Marocchi via swift-evolution \ wrote: > > > > > > > > Quite sad we could not get into ABI stability for Swift 3... but are we talking Swift 3.1 or 4.0? > > > > > > Disappointing is my first thought, in fact worrying. Two years after the language was announced, the ABI is still not stable. > > > > > > Of the original Swift 3 goals, it looks like many will not be met. There were seven goals and only two are still in the Readme file[1]. On the assumption that the other five were all dropped because they will not be achieved in Swift 3, this looks like failure. > > > > > > I’ve been following the evolution list on and off since it started and it hasn’t felt like failure. In fact, it felt like important progress has been made and the language will be hugely better for it, but I do hope that the development team does take the opportunity to review the release in light of the original goals to see if there are any opportunities to improve the development process for the next release. > > > > > > [1] [https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md](https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md) compared to [https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md](https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md) > > > > > > > Sent from my iPhone > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![jeremyp](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jeremyp/32/3552_2.png) [@jeremyp](https://forums.swift.org/u/jeremyp)\ **Post date:** [May 19, 2016, 9:12am UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/28 "2016-05-19T09:12:53Z")
> While on the face of it, you are correct, the goals have changed dramatically, I think you are being unfair. The goals changed dramatically last week. It’s there in the git history. Last week was \*after\* the first developer preview of Swift 3. I’m not being unfair, I’m being realistic. > Swift 3 initial scope was determined prior to the input of the Swift Evolution community, just as it was being Open Sourced. As we have explored the language in many discussions, it has been clear there are other areas of the language that needed clean and polish before a stable ABI can be established. I have no objection to having changed priorities, but these need to be communicated at the time the priorities change. When exactly was the stable ABI priority dropped? Was it last week, or was it months ago? Looking at the git history it was last week and the Swift community was not consulted in that change AFAIK. Nobody outside of the development team knew that all this debate about relatively minor language features was going to prevent us from meeting the goals for Swift 3. If we had known, maybe a lot of the issues that we did talk about would have been deferred instead of completing generics and a stable ABI. If somebody had said to you “we can make all these relatively minor changes to the language or we can complete generics, but not both” which would you have chosen? > It appears that this work is more involved than the Swift Team initially envisioned. The fact they are open to changing timelines and ensuring we get fundamentals of the language sorted is a testament to their commitment to the quality of Swift as a whole. Is completing the generic system fundamental or not? I’d say it is vastly more fundamental than removing C style for loops, wouldn’t you? > **···** > > > On 17 May 2016, at 14:38, Rod Brown \ wrote: ---
**Author:** ![jeremyp](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jeremyp/32/3552_2.png) [@jeremyp](https://forums.swift.org/u/jeremyp)\ **Post date:** [May 19, 2016, 9:33am UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/29 "2016-05-19T09:33:34Z")
> So I don’t mind (too much) if it takes longer to get a stable ABI. It > makes my life harder, but on the flip-side, I don’t want to be stuck > with yet another broken language and ABI. I want this done right > because it will be almost impossible to fix later. > > Here’s a simple, yet tragic example: BOOL in Objective-C. We were > stuck with signed char instead of getting a real boolean. Back in 10.4 > Tiger when the Intel migration was announced, I filed a bug report > reminding them that this was the chance to fix this. They didn’t fix > it, so we were stuck. Then I filed again in the 10.5 beta Leopard time > frame during the 64-bit transition, I filed again reminding them that > this should be fixed before the 64-bit ABI gets locked down. Again, it > wasn’t fixed so we were stuck. Then when the iOS SDK was going to > become public, I filed again. Still not fixed. Then armv7, still > nothing. Finally, for arm64, this was finally fixed. Too bad we’re > stuck on Mac with this probably forever. Objective-C had a real boolean type as soon as the compiler was C99 compatible and that’s when I started using it. BOOL is a typedef that is part of the Foundation/Cocoa API, not the Objective-C ABI. > Anyway, I don’t want to deal with another monstrous broken language. Objective-C is not broken. It’s a fine language that has served the Apple development community for at least 15 years. It has quirks and problems but it is fit for purpose. The first binary I compiled in 64 bit mode will still run on my current OS X 10.11 laptop. Swift is already vastly nicer to program in but if I was a PHB trying to decide whether to invest in Swift skills for the future, things like “unstable ABI” and “source code breaking changes for Swift 3” would be colouring my opinion now and not in a good way. I’d rather have a good language that is fit for production than one that is promised to be theoretically perfect at some as yet undefined future date. > **···** > > > On 17 May 2016, at 23:45, Eric Wing via swift-evolution \ wrote: ---
**Author:** ![Brent\_Royal-Gordon](https://avatars.discourse-cdn.com/v4/letter/b/53a042/32.png) [@Brent\_Royal-Gordon](https://forums.swift.org/u/Brent_Royal-Gordon)\ **Post date:** [May 19, 2016, 9:47am UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/30 "2016-05-19T09:47:36Z")
> Is completing the generic system fundamental or not? I’d say it is vastly more fundamental than removing C style for loops, wouldn’t you? Oh, come on. Removing the C-style for loop is not what took up time in this release cycle. What took up time is the API guidelines, the new collection model, and other standard library quality work—things which, in hindsight, are prerequisites for binary compatibility anyway, because linking against a different version doesn't count for much when all the names and calls have changed anyway. > **···** > > -- > Brent Royal-Gordon > Architechies ---
**Author:** ![zwaldowski](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/zwaldowski/32/21801_2.png) [@zwaldowski](https://forums.swift.org/u/zwaldowski)\ **Post date:** [May 19, 2016, 2:44pm UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/31 "2016-05-19T14:44:46Z")
> \> > \> So I don’t mind (too much) if it takes longer to get a stable ABI. It > \> makes my life harder, but on the flip-side, I don’t want to be stuck > \> with yet another broken language and ABI. I want this done right > \> because it will be almost impossible to fix later. > \> > \> Here’s a simple, yet tragic example: BOOL in Objective-C. We were > \> stuck with signed char instead of getting a real boolean. Back in 10.4 > \> Tiger when the Intel migration was announced, I filed a bug report > \> reminding them that this was the chance to fix this. They didn’t fix > \> it, so we were stuck. Then I filed again in the 10.5 beta Leopard time > \> frame during the 64-bit transition, I filed again reminding them that > \> this should be fixed before the 64-bit ABI gets locked down. Again, it > \> wasn’t fixed so we were stuck. Then when the iOS SDK was going to > \> become public, I filed again. Still not fixed. Then armv7, still > \> nothing. Finally, for arm64, this was finally fixed. Too bad we’re > \> stuck on Mac with this probably forever. > > Objective-C had a real boolean type as soon as the compiler was C99 > compatible and that’s when I started using it. BOOL is a typedef that is > part of the Foundation/Cocoa API, not the Objective-C ABI. > > \> > \> Anyway, I don’t want to deal with another monstrous broken language. > > Objective-C is not broken. It’s a fine language that has served the Apple > development community for at least 15 years. It has quirks and problems > but it is fit for purpose. The first binary I compiled in 64 bit mode > will still run on my current OS X 10.11 laptop. Swift is already vastly > nicer to program in but if I was a PHB trying to decide whether to invest > in Swift skills for the future, things like “unstable ABI” and “source > code breaking changes for Swift 3” would be colouring my opinion now and > not in a good way. > > I’d rather have a good language that is fit for production than one that > is promised to be theoretically perfect at some as yet undefined future > date. Much like people are expressing relief that the compatibility goals for the language are not being dictated by specific timelines, I would be wholly concerned if any of Swift's goals were being defined by winning the short-term favor of business people. > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > swift-evolution mailing list > swift-evolution@swift.org > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) Sincerely, Zachary Waldowski zach@waldowski.me > **···** > > On Thu, May 19, 2016, at 02:33 AM, Jeremy Pereira via swift-evolution wrote: > > > \> On 17 May 2016, at 23:45, Eric Wing via swift-evolution \ wrote: ---
**Author:** ![Shawn\_Erickson](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/shawn_erickson/32/2981_2.png) [@Shawn\_Erickson](https://forums.swift.org/u/Shawn_Erickson)\ **Post date:** [May 19, 2016, 3:10pm UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/32 "2016-05-19T15:10:52Z")
In the end it is just a version number. I don't think anyone would want to stop official releases of Swift while the rather long list of work items - let alone outstanding evolution discussions/reviews - get worked thru towards the goal of having strong source compatibility and stable ABI. It is obvious that the Swift community - including Apple - want to push the language farther forward then is possible in the original mindset for Swift 3. So the line won't be drawn in 3.0 but some future release... It likely won't change when that line will be drawn since that is being driven by the remaining work and evolution topics, it just changes what version number we associated with that line. I do think some more progress could be made by the larger community if a better way of engaging and maintaining non-Apple interested help while avoiding conflicts with unseen changes / decisions and reduce bottlenecks getting design and code reviews done in a more timely fashion. I know folks are very busy and it makes it difficult so I suggest additional staffing (could come from outside) to help support the community outside of Apple. -Shawn ---
**Author:** ![Eric\_Wing](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/eric_wing/32/3548_2.png) [@Eric\_Wing](https://forums.swift.org/u/Eric_Wing)\ **Post date:** [May 20, 2016, 12:49am UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/33 "2016-05-20T00:49:28Z")
> > Here’s a simple, yet tragic example: BOOL in Objective-C. We were > > stuck with signed char instead of getting a real boolean. Back in 10.4 > > Tiger when the Intel migration was announced, I filed a bug report > > reminding them that this was the chance to fix this. They didn’t fix > > it, so we were stuck. Then I filed again in the 10.5 beta Leopard time > > frame during the 64-bit transition, I filed again reminding them that > > this should be fixed before the 64-bit ABI gets locked down. Again, it > > wasn’t fixed so we were stuck. Then when the iOS SDK was going to > > become public, I filed again. Still not fixed. Then armv7, still > > nothing. Finally, for arm64, this was finally fixed. Too bad we’re > > stuck on Mac with this probably forever. > > Objective-C had a real boolean type as soon as the compiler was C99 > compatible and that’s when I started using it. BOOL is a typedef that is > part of the Foundation/Cocoa API, not the Objective-C ABI. I’m well aware of C99 \_Bool. However, this was a discussion of ABIs, and my point was how hard it is to change after the fact. And if you are going to nitpick, BOOL is defined in objc.h, not Foundation, AND it is now defined as C99 bool on arm64. The fact that Cocoa was unable to migrate to this repeatedly for about a decade proves my point. I also said booleans were a \*simple\* example of this. Greg Parker’s revelations of the lack of zero-cost exceptions on armv7 is something I completely forgot about reminded me of a low-level project I was I participated in a few years back where this implementation detail has terrible consequences for it. Getting the ABI right matters for so many reasons and percolates into everything. > > Anyway, I don’t want to deal with another monstrous broken language. > > Objective-C is not broken. I actually wasn’t referring to Objective-C nor accusing anybody at Apple or Swift of creating a monster. But I want to keep it that way, thus my support for delaying the stable ABI decision for Swift. -Eric ---
**Author:** ![jeremyp](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jeremyp/32/3552_2.png) [@jeremyp](https://forums.swift.org/u/jeremyp)\ **Post date:** [May 23, 2016, 9:17am UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/34 "2016-05-23T09:17:59Z")
> > Is completing the generic system fundamental or not? I’d say it is vastly more fundamental than removing C style for loops, wouldn’t you? > > Oh, come on. Removing the C-style for loop is not what took up time in this release cycle. What took up time is the API guidelines, the new collection model, and other standard library quality work—things which, in hindsight, are prerequisites for binary compatibility anyway, because linking against a different version doesn't count for much when all the names and calls have changed anyway. It is one of many things that have been done instead of concentrating on the goals as originally stated, five of which will not be met. The collection model, API guidelines and standard library are actually irrelevant to the ABI. The standard library API and the Swift ABI are distinct orthogonal concepts. > **···** > > > On 19 May 2016, at 10:47, Brent Royal-Gordon \ wrote: > > > -- > > Brent Royal-Gordon > > Architechies ---
**Author:** ![jeremyp](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jeremyp/32/3552_2.png) [@jeremyp](https://forums.swift.org/u/jeremyp)\ **Post date:** [May 23, 2016, 9:21am UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/35 "2016-05-23T09:21:35Z")
> Much like people are expressing relief that the compatibility goals for > the language are not being dictated by specific timelines, I would be > wholly concerned if any of Swift's goals were being defined by winning > the short-term favor of business people. The success of Swift as a language depends on the favour (short medium and long term) of business people. We have a choice here: we can either build the perfect ivory tower language that nobody uses outside of this group, or we can build a pragmatic language that is great for building real World applications in. I’d prefer we did the latter. > **···** > > > On 19 May 2016, at 15:44, Zach Waldowski via swift-evolution \ wrote: > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > Sincerely, > >   Zachary Waldowski > >   zach@waldowski.me > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Brent\_Royal-Gordon](https://avatars.discourse-cdn.com/v4/letter/b/53a042/32.png) [@Brent\_Royal-Gordon](https://forums.swift.org/u/Brent_Royal-Gordon)\ **Post date:** [May 23, 2016, 9:28am UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/36 "2016-05-23T09:28:56Z")
> The collection model, API guidelines and standard library are actually irrelevant to the ABI. The standard library API and the Swift ABI are distinct orthogonal concepts. I understand that. What I'm saying is, if we'd gotten a stable ABI in Swift 3 and a redesigned standard library in Swift 4 instead of the other way around, the standard library changes would've broken a lot of that "ABI-compatible" code anyway. (That, or we simply would've been stuck with the old, unimproved standard library.) > **···** > > -- > Brent Royal-Gordon > Architechies ---
**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\ **Post date:** [May 23, 2016, 11:21pm UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/37 "2016-05-23T23:21:20Z")
I’m not sure what you’re saying. If you change the API shipped by the standard library, it obviously breaks anything that links to it. The whole point of ABI stability is to not break apps built with old versions of Swift compiler / standard library. -Chris > **···** > > On May 23, 2016, at 2:17 AM, Jeremy Pereira via swift-evolution \ wrote: > > > The collection model, API guidelines and standard library are actually irrelevant to the ABI. The standard library API and the Swift ABI are distinct orthogonal concepts. ---
**Author:** ![L\_Mihalkovic](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/l_mihalkovic/32/5802_2.png) [@L\_Mihalkovic](https://forums.swift.org/u/L_Mihalkovic)\ **Post date:** [May 24, 2016, 7:00am UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/38 "2016-05-24T07:00:58Z")
> > The collection model, API guidelines and standard library are actually irrelevant to the ABI. The standard library API and the Swift ABI are distinct orthogonal concepts. > > I’m not sure what you’re saying. If you change the API shipped by the standard library, it obviously breaks anything that links to it. > > The whole point of ABI stability is to not break apps built with old versions of Swift compiler / standard library. > > -Chris I regularly read see how stability is a high prioriy goal going forward. But what I have not found yet what the plan is going to be to achieve it without stiffling the standard library? Are there constructs, or rules is place/planned that map how changes of kind A versus B level changes will be keeping/breaking compatibility? (I have not finished all the docs) > **···** > > > On May 24, 2016, at 1:21 AM, Chris Lattner via swift-evolution \ wrote: > > > > > On May 23, 2016, at 2:17 AM, Jeremy Pereira via swift-evolution \ wrote: > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\ **Post date:** [May 24, 2016, 5:56pm UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/39 "2016-05-24T17:56:27Z")
Once ABI stability is established, functionality can only be added to the standard library, not removed or have a significant behavior change. For example, fundamentally changing the index model for collections would be impossible, but adding a new kind of collection would be fine. -Chris > **···** > > > On May 24, 2016, at 12:00 AM, L. Mihalkovic \ wrote: > > > > > On May 24, 2016, at 1:21 AM, Chris Lattner via swift-evolution \ wrote: > > > > > > > On May 23, 2016, at 2:17 AM, Jeremy Pereira via swift-evolution \ wrote: > > > > The collection model, API guidelines and standard library are actually irrelevant to the ABI. The standard library API and the Swift ABI are distinct orthogonal concepts. > > > > > > I’m not sure what you’re saying. If you change the API shipped by the standard library, it obviously breaks anything that links to it. > > > > > > The whole point of ABI stability is to not break apps built with old versions of Swift compiler / standard library. > > > I regularly read see how stability is a high prioriy goal going forward. But what I have not found yet what the plan is going to be to achieve it without stiffling the standard library? Are there constructs, or rules is place/planned that map how changes of kind A versus B level changes will be keeping/breaking compatibility? (I have not finished all the docs) ---
**Author:** ![L\_Mihalkovic](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/l_mihalkovic/32/5802_2.png) [@L\_Mihalkovic](https://forums.swift.org/u/L_Mihalkovic)\ **Post date:** [May 24, 2016, 8:28pm UTC](https://forums.swift.org/t/winding-down-the-swift-3-release/2631/40 "2016-05-24T20:28:45Z")
> > > > The collection model, API guidelines and standard library are actually irrelevant to the ABI. The standard library API and the Swift ABI are distinct orthogonal concepts. > > > > > > I’m not sure what you’re saying. If you change the API shipped by the standard library, it obviously breaks anything that links to it. > > > > > > The whole point of ABI stability is to not break apps built with old versions of Swift compiler / standard library. > > > I regularly read see how stability is a high prioriy goal going forward. But what I have not found yet what the plan is going to be to achieve it without stiffling the standard library? Are there constructs, or rules is place/planned that map how changes of kind A versus B level changes will be keeping/breaking compatibility? (I have not finished all the docs) > > Once ABI stability is established, functionality can only be added to the standard library, not removed or have a significant behavior change. For example, fundamentally changing the index model for collections would be impossible, but adding a new kind of collection would be fine. Thank you for taking the time to reply. I am interested in understanding how finer granularity changes like adding methods to protocols, or adding new conformance requirements to existing types will or not impact compatibility. For eg I read about the possibility of upcoming default implementations in protocol. Is that part of the long term binary compatibility plans, or unrelated? I do realize many answers are in the compiler dev-list (read most but not all), the docs and the source code (have yet to read what's loaded at runtime from the binary) but any pointers would be appreciated. Thank you again. > **···** > > > On May 24, 2016, at 7:56 PM, Chris Lattner \ wrote: > > > > > On May 24, 2016, at 12:00 AM, L. Mihalkovic \ wrote: > > > > > > > > On May 24, 2016, at 1:21 AM, Chris Lattner via swift-evolution \ wrote: > > > > > On May 23, 2016, at 2:17 AM, Jeremy Pereira via swift-evolution \ wrote: > > > -Chris [Previous page](https://forums.swift.org/t/winding-down-the-swift-3-release/2631.md?page=1) [Next page](https://forums.swift.org/t/winding-down-the-swift-3-release/2631.md?page=3)