7 ms·

My memory might fail me, but I thought Swift 4 was supposed to be "the last major breakage"? Swift has a new major revision every year. Compare this to Go (no

My memory might fail me, but I thought Swift 4 was supposed to be "the last major breakage"? Swift has a new major revision every year. Compare this to Go (no major revisions after 6 years, probably a backwards-compatible major revision in 2-3 years) and Rust (no major revisions after 3 years, but with a mechanism called "editions"). To say nothing about Java or C#.

jedieaston 8y ago
I don't think Swift 5 is a major breakage. Swift 3 -> 4 code is compatible, so 4 -> 5 should be compatible too.
- ainar-g 8y ago
  >Swift 3 -> 4 code is compatible Is this really true? Looking through 4.0 release notes I see some incompatible changes like: SE-0164 Remove final support in protocol extensions SE-0160 Limiting @objc inference If your code compiled with the old version and doesn't with the new one, then those versions are incompatible.
  - airstrike 8y ago
    See https://docs.swift.org/swift-book/GuidedTour/Compatibility.html https://docs.swift.org/swift-book/GuidedTour/Compatibility.h... > When the Swift 4.2 compiler is working with Swift 3 code, it identifies its language version as 3.4. As a result, you can use conditional compilation blocks like #if swift(>=3.4) to write code that’s compatible with multiple versions of the Swift compiler.
  - slavapestov 8y ago
    The compiler has a -swift-version flag which gates the source-incompatible changes. There were a number of changes between -swift-version 3 and -swift-version 4, including the two you highlighted. The delta between -swift-version 4 and 4.2 released this year was much smaller.
    - coder543 8y ago
      it is worth noting that swift 3 support is being removed from swift 5.
    - ainar-g 8y ago
      That is compiler compatibility. I am talking about language-level compatibility. Yes, you can continue compiling v3 code with a v4 compiler with a flag, but if you compile your v3 code without a flag, your code may fail to compile. So while there may not be a compiler breakage, there is a language breakage between v3 and v4, and apparently there will be another one between v4 and v5.
      - slavapestov 8y ago
        That is right, but as I wrote in another reply here the changes from 4 to 5 are miniscule, mostly just fixing corner cases where the old behavior was not correct.
    - favorited 8y ago
      The real issue I encounter isn't Swift itself, it's the constant Swift-specific SDK changes... When the `NSNotification.Name` Swift APIs change every year, it means migration is still painful. It's not the Great Renaming, and it might not be fair to the Swift project itself, but unless I can compile a project using the 10.13 and 10.14 SDKs without source changes (which you can in Objective-C), the impression is that Swift doesn't have source compatibility.
      - saagarjha 8y ago
        As I'm sure you're aware, these are changes in AppKit, not Swift. AFAIK the Swift project has no control over how this API is exposed.
        favorited 8y ago
        I'm not disputing that. What I am saying is that, until the Swift representations of the Apple platform SDKs are stable between releases (like it is in Objective-C), then the majority of Swift codebases will not be source compatible the way Objective-C codebases are.
pwinnski 8y ago
If long-term stability is your goal, Swift is definitely not yet for you. Perhaps after v5, things will settle down. That seems to be what they're aiming for, but I would wait and see.
xenadu02 8y ago
Neither of those languages launched out of the gate with a stable ABI. Prior to Rust 1.0 it was much the same, with regular breaking changes. C++ famously took many years to have a stable ABI. Swift 5 represents a stable ABI. That means from this point forward all binaries built with Swift 5 or later will run against a newer Swift stdlib. The ABI is entirely separate from source compatibility. Swift is already source compatible and the bar for a source-breaking change is extremely high.
- slavapestov 8y ago
  Rust does not have a stable ABI.
- coder543 8y ago
  The Swift 5 release process document specifically implies that some Swift 4 code will not compile on Swift 5. This discussion is about source compatibility, not binary compatibility, which neither Rust nor Go offer AFAIK. The number 5 _also_ implies significant breaking changes. Otherwise, why wouldn't it be Swift 4.3? Removing Swift 3 compatibility mode (which was part of Swift 4) is itself a major source-compatibility breaking change, even if nothing else.
  - slavapestov 8y ago
    So far there are only a handful of small breaking changes between -swift-version 4 and -swift-version 5 on the master branch. The only ones I can think of are a type safety hole getting plugged and some warnings for corner cases around access control that got promoted to errors.
    - coder543 8y ago
      If that's the case, that's encouraging to hear.
  - saagarjha 8y ago
    "Source compatibility" for Swift means that the compiler provides a flag with that will allow it to compiler earlier versions of Swift.
melling 8y ago
Apple is pretty good about automating the conversion of Swift to the newer version. Swift 2 to 3 was a little bit of work but the new succinct syntax was worth it. It doesn’t sound like there will be many breaking changes in 5.0: “As with Swift 4.2, the vast majority of sources that built with the Swift 4.2 compiler should compile with the Swift 5.0 compiler”
raydev 8y ago
> but I thought Swift 4 was supposed to be "the last major breakage"? It wasn't even major. I updated several projects from Swift 3 to 4 without issue. The largest project was close to 200k loc and it only took me 20 minutes to get everything up to date. Just make sure your dependencies aren't in Swift because then you're relying on 3rd parties to update their code. I'll be avoiding all Swift libraries except for PromiseKit (it's so nice!).

jedieaston 8y ago

I don't think Swift 5 is a major breakage. Swift 3 -> 4 code is compatible, so 4 -> 5 should be compatible too.

ainar-g 8y ago
>Swift 3 -> 4 code is compatible Is this really true? Looking through 4.0 release notes I see some incompatible changes like: SE-0164 Remove final support in protocol extensions SE-0160 Limiting @objc inference If your code compiled with the old version and doesn't with the new one, then those versions are incompatible.
- airstrike 8y ago
  See https://docs.swift.org/swift-book/GuidedTour/Compatibility.html https://docs.swift.org/swift-book/GuidedTour/Compatibility.h... > When the Swift 4.2 compiler is working with Swift 3 code, it identifies its language version as 3.4. As a result, you can use conditional compilation blocks like #if swift(>=3.4) to write code that’s compatible with multiple versions of the Swift compiler.
- slavapestov 8y ago
  The compiler has a -swift-version flag which gates the source-incompatible changes. There were a number of changes between -swift-version 3 and -swift-version 4, including the two you highlighted. The delta between -swift-version 4 and 4.2 released this year was much smaller.
  - coder543 8y ago
    it is worth noting that swift 3 support is being removed from swift 5.
  - ainar-g 8y ago
    That is compiler compatibility. I am talking about language-level compatibility. Yes, you can continue compiling v3 code with a v4 compiler with a flag, but if you compile your v3 code without a flag, your code may fail to compile. So while there may not be a compiler breakage, there is a language breakage between v3 and v4, and apparently there will be another one between v4 and v5.
    - slavapestov 8y ago
      That is right, but as I wrote in another reply here the changes from 4 to 5 are miniscule, mostly just fixing corner cases where the old behavior was not correct.
  - favorited 8y ago
    The real issue I encounter isn't Swift itself, it's the constant Swift-specific SDK changes... When the `NSNotification.Name` Swift APIs change every year, it means migration is still painful. It's not the Great Renaming, and it might not be fair to the Swift project itself, but unless I can compile a project using the 10.13 and 10.14 SDKs without source changes (which you can in Objective-C), the impression is that Swift doesn't have source compatibility.
    - saagarjha 8y ago
      As I'm sure you're aware, these are changes in AppKit, not Swift. AFAIK the Swift project has no control over how this API is exposed.
      - favorited 8y ago
        I'm not disputing that. What I am saying is that, until the Swift representations of the Apple platform SDKs are stable between releases (like it is in Objective-C), then the majority of Swift codebases will not be source compatible the way Objective-C codebases are.

pwinnski 8y ago

If long-term stability is your goal, Swift is definitely not yet for you. Perhaps after v5, things will settle down. That seems to be what they're aiming for, but I would wait and see.

xenadu02 8y ago

Neither of those languages launched out of the gate with a stable ABI. Prior to Rust 1.0 it was much the same, with regular breaking changes. C++ famously took many years to have a stable ABI. Swift 5 represents a stable ABI. That means from this point forward all binaries built with Swift 5 or later will run against a newer Swift stdlib. The ABI is entirely separate from source compatibility. Swift is already source compatible and the bar for a source-breaking change is extremely high.

slavapestov 8y ago
Rust does not have a stable ABI.
coder543 8y ago
The Swift 5 release process document specifically implies that some Swift 4 code will not compile on Swift 5. This discussion is about source compatibility, not binary compatibility, which neither Rust nor Go offer AFAIK. The number 5 _also_ implies significant breaking changes. Otherwise, why wouldn't it be Swift 4.3? Removing Swift 3 compatibility mode (which was part of Swift 4) is itself a major source-compatibility breaking change, even if nothing else.
- slavapestov 8y ago
  So far there are only a handful of small breaking changes between -swift-version 4 and -swift-version 5 on the master branch. The only ones I can think of are a type safety hole getting plugged and some warnings for corner cases around access control that got promoted to errors.
  - coder543 8y ago
    If that's the case, that's encouraging to hear.
- saagarjha 8y ago
  "Source compatibility" for Swift means that the compiler provides a flag with that will allow it to compiler earlier versions of Swift.

melling 8y ago

Apple is pretty good about automating the conversion of Swift to the newer version. Swift 2 to 3 was a little bit of work but the new succinct syntax was worth it. It doesn’t sound like there will be many breaking changes in 5.0: “As with Swift 4.2, the vast majority of sources that built with the Swift 4.2 compiler should compile with the Swift 5.0 compiler”

raydev 8y ago

> but I thought Swift 4 was supposed to be "the last major breakage"? It wasn't even major. I updated several projects from Swift 3 to 4 without issue. The largest project was close to 200k loc and it only took me 20 minutes to get everything up to date. Just make sure your dependencies aren't in Swift because then you're relying on 3rd parties to update their code. I'll be avoiding all Swift libraries except for PromiseKit (it's so nice!).