4 ms·

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

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.
  - dbaupp 8y ago
    The Swift compiler does a lot of automatic "rewrites" of (Objective) C headers to be more Swifty, so it does have some measure of control. That said, the largest changes are guided by annotations associated with the headers.
  - Nullabillity 8y ago
    They're both ran by Apple, so that's a distinction without a difference.
    - saagarjha 8y ago
      Unfortunately, this isn't how Apple works. Both teams are more or less separate in this case. Sure, the Swift team can certainly send information over to the AppKit team, but they don't have the ability to make any decisions on naming conventions.

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.
- dbaupp 8y ago
  The Swift compiler does a lot of automatic "rewrites" of (Objective) C headers to be more Swifty, so it does have some measure of control. That said, the largest changes are guided by annotations associated with the headers.
- Nullabillity 8y ago
  They're both ran by Apple, so that's a distinction without a difference.
  - saagarjha 8y ago
    Unfortunately, this isn't how Apple works. Both teams are more or less separate in this case. Sure, the Swift team can certainly send information over to the AppKit team, but they don't have the ability to make any decisions on naming conventions.