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@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution Sincerely, Zachary Waldowski z...@waldowski.me _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution