[swift-evolution] Winding down the Swift 3 release
ewmailing at gmail.com
Tue May 17 17:45:53 CDT 2016
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).
More information about the swift-evolution