5 ms·

> It is not source-compatible with Swift 2.2 and 2.3. This created havoc in Python. Hopefully it won't happen here.

yoz-y 10y ago
Until now Swift has not promised source compatibility so the developers should be ready to rewrite their code for new versions. I would not be surprised if Swift 2.3 support were dropped in the next version of XCode completely. The migration tools are quite good though so going from 2.2 to 3.0 directly should not be much of a problem. I think that in Python the problem was/is that the 2.x was already a massively used and mature language when the 3 came out.
- cageface 10y ago
  The conversion tools failed pretty badly in my case. I had to do a ton of manual fixes. There are also still a lot of libraries out there that haven't updated yet so unfortunately I'm holding off on updating for now.
  - yoz-y 10y ago
    It is not perfect, but I would say it handled maybe 80% of stuff by itself. The one thing it could not solve for me was notification handling.
  - tonyjstark 10y ago
    For us it worked quite fine for macOS but not for iOS targets. It also changed the function names for a lot @IBAction functions but did not update the connection in the interface builder. So now I have to a lot of testing to make sure all buttons work. Still I have to admit it shows quite courage (get it?) to change so many things but naming is important and I see it positively. Only if Apple would use version numbers for Swift that would fit to the state, if you have that kind of fast update cycle and that many breaking changes a version number below 1.0 would have been better for Swift 1 and 2.
- groue 10y ago
  External librairies can also support the migration by providing "fix-its" which helps the compiler display an helpful message whenever a Swift 2-era line has not been updated to Swift 3 (see for example this PR: https://github.com/groue/GRDB.swift/pull/114 https://github.com/groue/GRDB.swift/pull/114)
0xmohit 10y ago
As per the blog [0], you can expect a lot to break. Swift 3 is a source-breaking release, largely due to the changes in SE-0005 and SE-0006. These changes not only impact the names of the Standard Library APIs, but also completely change how Objective-C APIs (particularly from Cocoa) import into Swift. Many of the changes are largely mechanical, but they can be numerous in a typical Swift project. To help with moving to Swift 3, Xcode 8.0 contains a code migrator that can automatically handle many of the need source changes. There is also a migration guide available to guide you through many of the changes — especially through the ones that are less mechanical and require more direct scrutiny. [0] https://swift.org/blog/swift-3-0-released/ https://swift.org/blog/swift-3-0-released/
jonathanstrange 10y ago
It makes a lot of sense, though. Like many new languages Swift was invented hastily and without much care with the main goal of locking in developers and preventing cross-platform development. If Apple made major releases backwards-compatible, this would invariably turn the language into a big mess in the long run. This way, the language can evolve into a fine language with many features from Algol-68 and the usual semi-popular C-ish syntax, and Apple can continue to ensure that developers have to maintain a separate codebase for their "apps" that is useless anywhere else.
- jasode 10y ago
  >Swift was invented hastily and without much care Swift was started in July 2010 by Chris Lattner[1] and it was publicly announced by Apple in June 2014 (and the 1.0 release was September 2014). Spending 4 years on it and including other programming language experts to contribute to it doesn't seem like a reckless and thoughtless release. What it shows is that even if a group spends years on it, they will still get a lot of things wrong. Same for C# that was (formally) started in January 1999 and not publicly released until December 2002. Even though that language also had 4 years of gestation by smart people, they still got generics and a bunch of other things wrong (e.g. terrible name of "destructors" for the concept of finalizers.) I didn't realize that programmers thought Swift was created in a hurry like Brendan Eich's "10 days" to design Livescript/Javascript for Netscape Navigator[2] [1]http://www.nondot.org/sabre/ http://www.nondot.org/sabre/ [2]https://www.quora.com/In-which-10-days-of-May-did-Brendan-Eich-write-JavaScript-Mocha-in-1995 https://www.quora.com/In-which-10-days-of-May-did-Brendan-Ei...
  - cageface 10y ago
    I like Swift but it really was released too early. There were fundamental problems with the tooling for a long long time after the first release and there has been a lot of churn in the syntax even after the tooling started to settle down. Designing a language like Swift is hard and it's not reasonable to expect them to get everything right on the first try but I do think it would have benefitted from a lot more dogfooding before they started pushing it on developers.
kalleboo 10y ago
Almost every version of Swift until now has had source-breaking changes. We're used to fixing things every 6 months or so.
cageface 10y ago
It has also created havoc in the Swift world. Suddenly all existing Swift code is broken. The migration tool is supposed to take care of most of this for you but my experience has been that it misses a lot of things and upgrading requires many manual fixes. Of course every Swift library in existence also needs to be updated so your changes of a smooth migration right now are slim. Apple has the resources to push this through and developers don't really have much choice so I don't expect this to become another Python 3 fiasco but this really should be the last time Apple breaks so much code just to clean up the syntax a bit.
masklinn 10y ago
> This created havoc in Python. Hopefully it won't happen here. There are big differences though: * Python had 15 years of source-compatibility before the switch, Swift has 1 year and a history of source-incompatibility (Swift 2 was not source-compatible with Swift 1) * Python had a fair amount of semantic-incompatibility * Python doesn't have a (heavy) compiler backing it up making source and semantic incompatibilities runtime issues your program bashes its face in rather than cascading compilation failures
- melling 10y ago
  It won't happen because Apple won't give you the option. Swift 3.x has a large amount of syntax changes. The compiler helps with the refactoring but it's still work.
  - masklinn 10y ago
    > It won't happen because Apple won't give you the option. What won't happen, havoc in the ecosystem? How is Apple relevant? > Swift 3.x has a large amount of syntax changes. Yes? > The compiler helps with the refactoring but it's still work. That's not what I'm talking about. A bit of drudge work is fine, the issue of the Python transition is that you get usually hard to debug runtime failures down the line, possibly for a long, long time. With Swift, I assume the compiler just keeps complaining until you've converted everything more or less properly, you may have a few nits but you don't keep finding new breakages.
    - melling 10y ago
      What won't happen is that Apple won't let people build against old versions of Swift. We'll all be on 3.x soon. I have no idea how hard the conversion of a large Python 2 to 3 project is. My projects were small and I had no troubles. At any rate 2020 will be here soon and 2.x support will end. All Swift users will be on 6.x by then.

yoz-y 10y ago

Until now Swift has not promised source compatibility so the developers should be ready to rewrite their code for new versions. I would not be surprised if Swift 2.3 support were dropped in the next version of XCode completely. The migration tools are quite good though so going from 2.2 to 3.0 directly should not be much of a problem. I think that in Python the problem was/is that the 2.x was already a massively used and mature language when the 3 came out.

cageface 10y ago
The conversion tools failed pretty badly in my case. I had to do a ton of manual fixes. There are also still a lot of libraries out there that haven't updated yet so unfortunately I'm holding off on updating for now.
- yoz-y 10y ago
  It is not perfect, but I would say it handled maybe 80% of stuff by itself. The one thing it could not solve for me was notification handling.
- tonyjstark 10y ago
  For us it worked quite fine for macOS but not for iOS targets. It also changed the function names for a lot @IBAction functions but did not update the connection in the interface builder. So now I have to a lot of testing to make sure all buttons work. Still I have to admit it shows quite courage (get it?) to change so many things but naming is important and I see it positively. Only if Apple would use version numbers for Swift that would fit to the state, if you have that kind of fast update cycle and that many breaking changes a version number below 1.0 would have been better for Swift 1 and 2.
groue 10y ago
External librairies can also support the migration by providing "fix-its" which helps the compiler display an helpful message whenever a Swift 2-era line has not been updated to Swift 3 (see for example this PR: https://github.com/groue/GRDB.swift/pull/114 https://github.com/groue/GRDB.swift/pull/114)

0xmohit 10y ago

As per the blog [0], you can expect a lot to break. Swift 3 is a source-breaking release, largely due to the changes in SE-0005 and SE-0006. These changes not only impact the names of the Standard Library APIs, but also completely change how Objective-C APIs (particularly from Cocoa) import into Swift. Many of the changes are largely mechanical, but they can be numerous in a typical Swift project. To help with moving to Swift 3, Xcode 8.0 contains a code migrator that can automatically handle many of the need source changes. There is also a migration guide available to guide you through many of the changes — especially through the ones that are less mechanical and require more direct scrutiny. [0] https://swift.org/blog/swift-3-0-released/ https://swift.org/blog/swift-3-0-released/

jonathanstrange 10y ago

It makes a lot of sense, though. Like many new languages Swift was invented hastily and without much care with the main goal of locking in developers and preventing cross-platform development. If Apple made major releases backwards-compatible, this would invariably turn the language into a big mess in the long run. This way, the language can evolve into a fine language with many features from Algol-68 and the usual semi-popular C-ish syntax, and Apple can continue to ensure that developers have to maintain a separate codebase for their "apps" that is useless anywhere else.

jasode 10y ago
>Swift was invented hastily and without much care Swift was started in July 2010 by Chris Lattner[1] and it was publicly announced by Apple in June 2014 (and the 1.0 release was September 2014). Spending 4 years on it and including other programming language experts to contribute to it doesn't seem like a reckless and thoughtless release. What it shows is that even if a group spends years on it, they will still get a lot of things wrong. Same for C# that was (formally) started in January 1999 and not publicly released until December 2002. Even though that language also had 4 years of gestation by smart people, they still got generics and a bunch of other things wrong (e.g. terrible name of "destructors" for the concept of finalizers.) I didn't realize that programmers thought Swift was created in a hurry like Brendan Eich's "10 days" to design Livescript/Javascript for Netscape Navigator[2] [1]http://www.nondot.org/sabre/ http://www.nondot.org/sabre/ [2]https://www.quora.com/In-which-10-days-of-May-did-Brendan-Eich-write-JavaScript-Mocha-in-1995 https://www.quora.com/In-which-10-days-of-May-did-Brendan-Ei...
- cageface 10y ago
  I like Swift but it really was released too early. There were fundamental problems with the tooling for a long long time after the first release and there has been a lot of churn in the syntax even after the tooling started to settle down. Designing a language like Swift is hard and it's not reasonable to expect them to get everything right on the first try but I do think it would have benefitted from a lot more dogfooding before they started pushing it on developers.

kalleboo 10y ago

Almost every version of Swift until now has had source-breaking changes. We're used to fixing things every 6 months or so.

cageface 10y ago

It has also created havoc in the Swift world. Suddenly all existing Swift code is broken. The migration tool is supposed to take care of most of this for you but my experience has been that it misses a lot of things and upgrading requires many manual fixes. Of course every Swift library in existence also needs to be updated so your changes of a smooth migration right now are slim. Apple has the resources to push this through and developers don't really have much choice so I don't expect this to become another Python 3 fiasco but this really should be the last time Apple breaks so much code just to clean up the syntax a bit.

masklinn 10y ago

> This created havoc in Python. Hopefully it won't happen here. There are big differences though: * Python had 15 years of source-compatibility before the switch, Swift has 1 year and a history of source-incompatibility (Swift 2 was not source-compatible with Swift 1) * Python had a fair amount of semantic-incompatibility * Python doesn't have a (heavy) compiler backing it up making source and semantic incompatibilities runtime issues your program bashes its face in rather than cascading compilation failures

melling 10y ago
It won't happen because Apple won't give you the option. Swift 3.x has a large amount of syntax changes. The compiler helps with the refactoring but it's still work.
- masklinn 10y ago
  > It won't happen because Apple won't give you the option. What won't happen, havoc in the ecosystem? How is Apple relevant? > Swift 3.x has a large amount of syntax changes. Yes? > The compiler helps with the refactoring but it's still work. That's not what I'm talking about. A bit of drudge work is fine, the issue of the Python transition is that you get usually hard to debug runtime failures down the line, possibly for a long, long time. With Swift, I assume the compiler just keeps complaining until you've converted everything more or less properly, you may have a few nits but you don't keep finding new breakages.
  - melling 10y ago
    What won't happen is that Apple won't let people build against old versions of Swift. We'll all be on 3.x soon. I have no idea how hard the conversion of a large Python 2 to 3 project is. My projects were small and I had no troubles. At any rate 2020 will be here soon and 2.x support will end. All Swift users will be on 6.x by then.