[swift-evolution] Winding down the Swift 3 release

[Zach Waldowski]

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 <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.

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
> https://lists.swift.org/mailman/listinfo/swift-evolution

Sincerely,
  Zachary Waldowski
  zach at waldowski.me