Apple Releases Swift 3.0, 'Not Source-Compatibile With Swift 2.3' (infoworld.com)

An anonymous Slashdot reader quotes InfoWorld: "Move fast and break things," the saying goes. Apple does both with the 3.0 version of its Swift programming language...its first full point revision since it became an open source project... In a blog post detailing the full body of changes for Swift 3.0, Apple singled out the two biggest breaking changes. The first is better translation of Objective-C APIs into Swift, meaning that code imported from Objective-C and translated into Swift will be more readable and Swift-like. The bad news is any code previously imported from Objective-C into Swift will not work in Swift 3; it will need to be re-imported.

The other major change... Most every item referenced in the standard library has been renamed to be less wordy. But again, this brings bad news for anyone with an existing Swift codebase: Apple says "the proposed changes are massively source-breaking for Swift code, and will require a migrator to translate Swift 2 code into Swift 3 code."
Apple will provide migration tools in version 8.0 of their XCode IDE, "but such tools go only so far," notes the article, questioning what will happen to the Linux and Windows ports of Swift.

Comments

Breathes new life into old APIs

[SuperKendall]

I have a pretty decent amount of Swift and the change between this version and previous versions is a lot more to absorb than it has been in the past... the migrator tool does help though it seems like it doesn't do as much as it could (that may have changed from earlier betas though).

However, whatever brief pain this brings upon us, is more than made up by the improvements Swift3 brings to the Cocoa API...

Have you ever worked on an Api for a long time, and thought "if I could do this again I'd rename all this stuff, and structure this one thing differently..."

Well that's one thing Swift3 did for Cocoa - there's basically a whole new name mapping overlay for Cocoa that makes lots and lots of calls much clearer, and also extensions that offer more Swift friendly API calls in some cases.

And the nice thing is some of the mappings are algorithmic, so your own ObjectiveC code you call from Swift benefits from name tidying or simplification, which works out well because of naming conventions Cocoa has long had and almost all Cocoa programmers follow.

There are also specially tweaked mappings to some parts where special cases made the automatic mapping not make sense, so it's like the whole API has had an overview and some re-thought applied.

It is sad that Swift3 could not yet bring ABI stabilization (so you could ship binaries of libraries to other developers and have them work in future Swift updates). But hey, the upside there is that people that want to ship Swift libraries have to give you source - who doesn't want that!

Re:welcome to python

[MSG]

Python was initially released in January 1994, almost 23 years ago. Since then, some libraries have been deprecated, first producing warnings, and later being removed. That process gave users and developers time to update the code without completely breaking following an upgrade. Backward compatibility was reasonably well maintained until 3.0, which was released in parallel with 2.6. Python 2 is still maintained while developers port code to Python 3.

That's a big contrast from Swift, which was initially released almost exactly 2 years ago, and made significant backward-incompatible changes without an interim version that retained compatibility. Python's not perfectly backward compatible, but it's a whole lot better than this.

Re:welcome to python

[Anonymous Coward]

Python 2 is still maintained because the installed base of useful Python 2 code is extremely big. People are porting to 3, but it takes time.

And the actual changes are much smaller in Python 3, here the new Swift is completely changing a lot of APIs without notice nor deprecated phase.

This thread is full of anti-Apple haters

[Anonymous Coward]

Everybody whining here clearly hasn't written any Swift code and is only interested in bashing Apple. Maybe you should be asking what actual people using Swift think of this.

Well, I'll tell you as one.

- The Swift syntax changes are annoying to spend time on, but minor.
- Apple's migration tool is helpful and makes fixing go fast.
- It was no surprise or secret that the syntax was going to change. They said all this upfront and we all knew this was coming.
- Swift on Linux and other platforms only started working less than a year ago. There is not as much code to transition.

And Thus the Reason for Swift 2.3

[rsmith-mac]

What TFS doesn't do a good job of explaining is that with Swift 3, Apple has essentially forked the project into two parts. Besides the newer version 3, Apple is also continuing to develop/support Swift 2.x. The already-released Swift 2.3 is Swift 3's counterpart for developers who would like to stick with Swift 2.x code.

Swift 2.3 is a minor update from Swift 2.2.1. The primary difference between Swift 2.2.1 and Swift 2.3 is that it is intended to be paired with Apple's macOS 10.12, iOS 10, watchOS 3, and tvOS 10 SDKs. It also updates the underlying LLVM and Clang versions to match with those in the Swift 3 compiler.

I don't imagine Apple will support Swift 2.x forever. But for the time being, Swift 3 is only as source-breaking as you want it to be. Developers who need Swift 2 compatibility can roll on with 2.3.

Re:Swift is always doing non compat updates

[Brett Diamond]

The ++ operator is not the same as += 1 operation. For example,

var a = 3
let b = a++ * 3

Now, I expect this type of code is the justification Apple is using to remove the operator; although there is no ambiguity, the line which sets b also sets a.

I argue that prefix and postfix ++ and -- should have remained in Swift. Not only are they well defined, but they are a standard operator in almost all new languages and therefore convey their meaning to the application developer significantly better than += 1 or -= 1 ever could.

For example, when reading code, ++i requires significantly less reading and parsing by the developer than i += 1 to convey the same idea.