[swift-evolution] Winding down the Swift 3 release

Jeremy Pereira jeremy.j.pereira at googlemail.com
Thu May 19 04:33:34 CDT 2016

> On 17 May 2016, at 23:45, 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.

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.

More information about the swift-evolution mailing list