[swift-evolution] Winding down the Swift 3 release

[Greg Parker]

> On May 17, 2016, at 3:45 PM, Eric Wing via swift-evolution <swift-evolution at swift.org> 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.

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.


-- 
Greg Parker     gparker at apple.com <mailto:gparker at apple.com>     Runtime Wrangler


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160517/aad8f235/attachment.html>