4 ms·

I'm wondering if this means that the major work on Swift the language is complete? I've avoided it since it seems every year the language or the API changes...

I'm wondering if this means that the major work on Swift the language is complete? I've avoided it since it seems every year the language or the API changes... has it now settled? I really didn't want to go back rewriting code every year.

AlexeyBrin 10y ago
They've promised source code compatibility starting with Swift 3.0 and up. This means that in theory you should be able to recompile a Swift 3 code with the Swift 4 compiler.
- kibwen 10y ago
  There's some nuance to the definition of source code compatibility: > The Swift 4 compiler will include a language compatibility flag -swift-version that accepts 3 or 4 as arguments and controls the compatibility mode (SR- 2582 <https://bugs.swift.org/browse/SR-2582> https://bugs.swift.org/browse/SR-2582>). > The -swift-version 3 compatibility mode has the goal of source compatibility as much as practically possible with Swift 3.x (including 3, 3.0.x, 3.x). > The -swift-version 4 compatibility allows approved source code breakages from Swift 3.x (including 3, 3.0.x, 3.x). https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161128/029099.html https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo... TL;DR: there may be breaking source changes between Swift 3 and Swift 4, but the Swift 4 compiler will still be capable of compiling Swift 3 code. There's no indication whether the Swift 5 compiler will still be able to compile Swift 3 code, so you'll likely still have to migrate your codebase within a year or two.
emdowling 10y ago
By all accounts, we won't see another change on the same level as Swift 2.0 -> Swift 3.0 for some time. Having shipped production apps for all major releases of Swift, it definitely feels like the syntax and foundation of the language has settled in 3.0. Now it seems more focused on building on top of that.
asow92 10y ago
If you're truly worried, I would hold off just a little bit longer. Swift ABI stability is slated for Swift 4.
- mozumder 10y ago
  Is that expected this summer?
  - mikeash 10y ago
    Swift seems to be locked to Apple's yearly release schedule, so we should see prerelease versions of Swift 4 this summer, followed by a public 4.0 release around September.
- stepanhruda 10y ago
  ABI stability doesn't really matter for users, unless you're using 3rd party pre-compiled libraries. It's mainly an issue for Apple, shipping system libraries.
  - mnem 10y ago
    It's quite important if you're trying to provide libraries for developers to use...
    - stepanhruda 10y ago
      Closed source libraries.
manmal 10y ago
Swift 4 will be ABI stable, i.e. you will be able to use Swift 4 binaries with Swift 5. So, starting in September things will really settle down, or at least, upgrades are not a problem anymore. I guess that XCode will stay compatible with Swift 4+ for a long time in the future, and it might even mean that changes in Swift 5+ will only be additions, like blocks in Obj-C were. UPDATE: Another comment here says that code compatibility is already fixed with Swift 3+.
- timjver 10y ago
  Swift 3 code will be able to be used alongside Swift 4 code, in the future, but that's not to say that Swift 4 won't contain any breaking changes (it will).
  - manmal 10y ago
    Do you mean mixing 3 and 4 will work only if kept in separate source files?
adamnemecek 10y ago
> I really didn't want to go back rewriting code every year. The changes are mostly syntactic and like API changes. And Xcode has an integrated migration tool that's not too bad. I ported approx. 23KLOC of Swift (http://audiokit.io http://audiokit.io) from 2 to 3 in like 3 hours. And the changes are generally for the better.
- Grustaf 10y ago
  Exactly my experience, I don't see why people complain about swift "always changing". I spent less than a working day in total on upgrading and I've been using only swift since it was launched. I don't like the new () requirement on method signature input types though...
- joelhaasnoot 10y ago
  It can also be utter hell though if you rely on lots of external dependencies that don't share the same lifecycle.
  - adamnemecek 10y ago
    That is definitely true.
J0-nas 10y ago
At the IBM event he said that the current concurrency model (gcd) might be replaced/extended by an actor/task based model in version 5.

AlexeyBrin 10y ago

They've promised source code compatibility starting with Swift 3.0 and up. This means that in theory you should be able to recompile a Swift 3 code with the Swift 4 compiler.

kibwen 10y ago
There's some nuance to the definition of source code compatibility: > The Swift 4 compiler will include a language compatibility flag -swift-version that accepts 3 or 4 as arguments and controls the compatibility mode (SR- 2582 <https://bugs.swift.org/browse/SR-2582> https://bugs.swift.org/browse/SR-2582>). > The -swift-version 3 compatibility mode has the goal of source compatibility as much as practically possible with Swift 3.x (including 3, 3.0.x, 3.x). > The -swift-version 4 compatibility allows approved source code breakages from Swift 3.x (including 3, 3.0.x, 3.x). https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161128/029099.html https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo... TL;DR: there may be breaking source changes between Swift 3 and Swift 4, but the Swift 4 compiler will still be capable of compiling Swift 3 code. There's no indication whether the Swift 5 compiler will still be able to compile Swift 3 code, so you'll likely still have to migrate your codebase within a year or two.

emdowling 10y ago

By all accounts, we won't see another change on the same level as Swift 2.0 -> Swift 3.0 for some time. Having shipped production apps for all major releases of Swift, it definitely feels like the syntax and foundation of the language has settled in 3.0. Now it seems more focused on building on top of that.

asow92 10y ago

If you're truly worried, I would hold off just a little bit longer. Swift ABI stability is slated for Swift 4.

mozumder 10y ago
Is that expected this summer?
- mikeash 10y ago
  Swift seems to be locked to Apple's yearly release schedule, so we should see prerelease versions of Swift 4 this summer, followed by a public 4.0 release around September.
stepanhruda 10y ago
ABI stability doesn't really matter for users, unless you're using 3rd party pre-compiled libraries. It's mainly an issue for Apple, shipping system libraries.
- mnem 10y ago
  It's quite important if you're trying to provide libraries for developers to use...
  - stepanhruda 10y ago
    Closed source libraries.

manmal 10y ago

Swift 4 will be ABI stable, i.e. you will be able to use Swift 4 binaries with Swift 5. So, starting in September things will really settle down, or at least, upgrades are not a problem anymore. I guess that XCode will stay compatible with Swift 4+ for a long time in the future, and it might even mean that changes in Swift 5+ will only be additions, like blocks in Obj-C were. UPDATE: Another comment here says that code compatibility is already fixed with Swift 3+.

timjver 10y ago
Swift 3 code will be able to be used alongside Swift 4 code, in the future, but that's not to say that Swift 4 won't contain any breaking changes (it will).
- manmal 10y ago
  Do you mean mixing 3 and 4 will work only if kept in separate source files?

adamnemecek 10y ago

> I really didn't want to go back rewriting code every year. The changes are mostly syntactic and like API changes. And Xcode has an integrated migration tool that's not too bad. I ported approx. 23KLOC of Swift (http://audiokit.io http://audiokit.io) from 2 to 3 in like 3 hours. And the changes are generally for the better.

Grustaf 10y ago
Exactly my experience, I don't see why people complain about swift "always changing". I spent less than a working day in total on upgrading and I've been using only swift since it was launched. I don't like the new () requirement on method signature input types though...
joelhaasnoot 10y ago
It can also be utter hell though if you rely on lots of external dependencies that don't share the same lifecycle.
- adamnemecek 10y ago
  That is definitely true.

J0-nas 10y ago

At the IBM event he said that the current concurrency model (gcd) might be replaced/extended by an actor/task based model in version 5.