[swift-evolution] Winding down the Swift 3 release
zach at waldowski.me
Thu May 19 09:44:46 CDT 2016
On Thu, May 19, 2016, at 02:33 AM, Jeremy Pereira via swift-evolution
> > 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
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 at swift.org
zach at waldowski.me
More information about the swift-evolution