10 ms·

Swift 3.1 Released

167 points by okket 10y ago

jordansmithnz 10y ago
A week or two ago I updated a fairly large project to 3.1. Not as painful as the 3.0 upgrade by any means, but there were still a fair few warnings about features that will be deprecated in future releases. Dropping support for the initialize() function was probably one of the most prominent. To me that seems like a nice way of doing it - warning developers about approaching changes with a fairly strong warning message, and allowing time for those changes to take place.
- slavapestov 10y ago
  Most of the new warnings in 3.1 were with things that never should have worked in the first place (some stuff with public declarations referencing private typealiases in their type signatures and things like that). There were also some new warnings added for mixed type arithmetic which is a common source of surprising behavior. The initialize thing is as far as I understand due to a limitation in the Objective C runtime and overriding initialize in Swift never fully worked in the first place. If you feel the 3.0 to 3.1 migration was still too painful from a compatibility perspective, it is not too late to file bugs; Swift 4 will still remain compatible with Swift 3 source so we can make further adjustments to the type checker if needed.
dep_b 10y ago
Hopefully it has support for warnings when formatting strings with optional values: http://stackoverflow.com/questions/42045139/i-want-a-compiler-warning-or-error-when-i-use-a-wrapped-string-in-formatting http://stackoverflow.com/questions/42045139/i-want-a-compile...
- jordansmithnz 10y ago
  Good news - it does. For me, it fixed a lot of bugs that I had no idea existed. Seems like a pretty easy mistake to make, since third party libraries I use were littered with exactly the same mistake.
  - dep_b 10y ago
    Yep it was a really nasty one. Because it used to work differently in Swift 2.x where it would not put Optional() around it in certain circumstances.
    - glhaynes 10y ago
      Interesting, I don't remember noticing it behaving that way. What were the circumstances, if you recall?
      - slavapestov 10y ago
        I think there were differences around calling .description versus .debugDescription when a type is converted to a String, which had some odd behavior with Optional. I think there was an evolution thread about this but you'll have to Google it yourself since I'm on my phone right now :-)
      - dep_b 10y ago
        var someInt: Int! // class parameter // later, in a method let url = "/api/bla/\(someInt)" In Swift 2.x it would simply show the value of someInt. Now it will print Optional. The problem is described in the linked Stack Overflow question as well. I never program like that but there's a ton of people out there that convince the compiler they're going to set that value in time even when it's not set when init is called. Just like some people (including Apple!) use this pattern for setting outlets: IBOutlet var someLabel: UILabel!
misterdata 10y ago
Just installed, compiling a fairly large project gives me "Command failed due to signal: Illegal instruction: 4" without any further information. Smooth...
- okket 10y ago
  Congratulations, you managed to crash the compiler. Can you please file a bug? https://swift.org/contributing/#reporting-bugs https://swift.org/contributing/#reporting-bugs
  - misterdata 10y ago
    Of course, just did. Very surprised that this happens for a 'source compatible' point release of Swift. Especially as this can be triggered with only five fairly simple lines of code. Not good.
    - okket 10y ago
      Thank you!
    - numerlo 10y ago
      Well they are called bugs and they exist in every software. It's not like they did it on purpose.
      - devsquid 10y ago
        Yea, but the Swift compiler is extremely buggy. Plus its gotten buggier with each release.
        flipgimble 10y ago
        That sounds like you are making engineering decisions by superstition. Unless you have some source of data to back it up, please don't spread your subjective misinformation.
    - 10y ago
akanet 10y ago
Does anyone know where the new Linux binaries are? The release announcement links to https://swift.org/download https://swift.org/download, but I can't actually find the 3.1 binaries anywhere.
- vetinari 10y ago
  There are neither source releases, nor tags in git repository yet (except the 'swift' repository).
  - slavapestov 10y ago
    You can download a 3.1 development snapshot. I'm not involved in preparing the official releases but I'm assuming the Linux 3.1 release will be very close to what is in swift-3.1-branch now. And all the action these days is on the master branch so if you're on Linux and want to help us squash regressions you should periodically test your codebase with master snapshots.
    - vetinari 10y ago
      At this stage, I'm more interested in properly packaging it (for a non-Ubuntu distribution), than compiler development itself. Not having at least tags for the release is very unusual, especially given the title of this article ;). As it is composed from multiple packages, there are too many moving parts than may or may not fit together. It would be great, if there was a tag+source tarball for each release. I'm sure internally there must be something, your colleagues certainly must know, to which commit 'Apple Swift version 3.1 (swiftlang-802.0.48 clang-802.0.38)' maps to.
      - alblue 10y ago
        There is a tag for the release, called swift-3.1-RELEASE: https://github.com/apple/swift/tree/swift-3.1-RELEASE https://github.com/apple/swift/tree/swift-3.1-RELEASE It's not showing up on GitHub's UI nor search for me at present, which may be why it seems like it's missing. You can download a .tgz from GitHub but bear in mind that you have to do the same for each of the nested repositories as well. If you're building it for yourself, it's easier to download the swift-3.1-RELEASE content, and then run 'utils/update-checkout --clone --skip-history --tag swift-3.1-RELEASE' to procure the rest of the repositories. There are a number of bugs to work on Swift packages for RHEL/CentOS: https://bugs.swift.org/browse/SR-100 https://bugs.swift.org/browse/SR-100 https://bugs.swift.org/browse/SR-108 https://bugs.swift.org/browse/SR-108 https://bugs.swift.org/browse/SR-116 https://bugs.swift.org/browse/SR-116 The issues are primarily around those operating systems having too old a version of Clang in their default repositories to be able to bootstrap the newer builds, and the fact that they don't have the blocks runtime available, both of which are used by the Swift runtime.
mixmastamyk 10y ago
Interesting to hear that IBM helped improve the release on Linux, thanks. I may consider it for a project in the future.
- pjmlp 10y ago
  Yes, IBM is putting some money into supporting Swift, just like they did with Java in the early days. https://developer.ibm.com/swift/ https://developer.ibm.com/swift/ https://developer.ibm.com/swift/kitura/ https://developer.ibm.com/swift/kitura/ https://www.ibm.com/cloud-computing/bluemix/de/swift https://www.ibm.com/cloud-computing/bluemix/de/swift
dilap 10y ago
Used objc a bit; never used swift. Question about this signature: func drop(while predicate: (Self.Iterator.Element) throws -> Bool) rethrows -> Self.SubSequence I take it the "throws" on the type of predicate means it can 'throw/return' an error. Why would you do this? Why not just require your predicate function to be able to process any element? Or I am confused? It seems like the equivalent in Go, for example, would be something like this func drop(seq []T, while func(T) (bool, error)) ([]T, error) which, again, seems like madness. Or am I confused?
- mayoff 10y ago
  First, why not allow your predicate to throw? Maybe your program will be better structured that way. Second, if you pass a predicate that is not declared `throws`, then the compiler treats `drop(while:)` as if it cannot throw either. This is what `rethrows` means: it makes `drop(while:)` covariant (in terms of throws-ness) with `predicate`.
- slavapestov 10y ago
  With 'drop' passing a throwing predicate feels a bit esoteric, but consider something like 'map'. Suppose you are mapping over an array of file names and loading each one, which can throw. You would expect the 'map' itself to throw if processing one of the elements throws. You can write higher order functions that only take total functions as arguments and handle errors with an 'Either' type, which is more general but creates boilerplate. Also 'rethrows' is a special keyword that means if you pass in a function that does not throw, the overall operation won't throw either. So mapping over an array of integers to increment each one won't require error handling, since the operation itself cannot fail.
  - dilap 10y ago
    Ah, OK, interesting. Thanks for the response.
  - Someone 10y ago
    "So mapping over an array of integers to increment each one won't require error handling, since the operation itself cannot fail." Nitpick: in Swift, "since the operation itself cannot fail" isn't correct. The operation will fail on overflow, but it will terminate your application rather than throw.
adomanico 10y ago
Very anecdotal evidence: I work on a fairly large mixed Swift & Objc project and I was expecting a greater decrease in compile times. At first it seemed 'snappier' but starting to notice not much of an improvement. It definitely still feels like making small changes like changing a function name triggers a lot of extra work. I should fire up some benchmarking of Swift 3.1 vs 3.0
- slavapestov 10y ago
  There are two main sources of slow compile times in Swift -- the expression type checker has exponential in the presence of large numbers of overloads (which unfortunately includes arithmetic expressions and collection literals). The second is what I think you're hitting which is that incremental builds sometimes rebuild too many files because the dependency tracking is overly conservative. There was some work on the expression type checker in 3.1 (string interpolation, casts and a limited "domain shrinking" pass to simplify some arithmetic expressions) but the main focus there was centered on the declaration checker, in particular up the generics implementation to fix lots of crashes and limitations. Both the expression checker and incremental builds should receive more attention going forward though. In the meantime the usual workarounds might help - splitting up your codebase into multiple Swift modules ("targets" in Xcode), and splitting up complex expressions and adding explicit type annotations.
- slavapestov 10y ago
  Also have you tried enabling precompiled bridging headers? This was added in 3.1 with the goal of speeding up mixed Swift/ObjC builds (by none other than Graydon Hoare), but other than that I don't know much about it.
  - adomanico 10y ago
    My understanding was that this was enabled by default
  - adomanico 10y ago
    It looks like it was actually disabled before release https://github.com/apple/swift/commit/5b9166ba8098a23e0601aac96ede363dea2484ae https://github.com/apple/swift/commit/5b9166ba8098a23e0601aa...
adrianotadao 10y ago
I like Swift but I hate the Xcode and the Apple tools. Is so painful to code with it. Apple needs to change its entire development flow. Even working with the react-native I need to use Xcode. =l
- ryanbertrand 10y ago
  Have you tried the JetBrains AppCode IDE?
  - adrianotadao 10y ago
    Never, is it a good choice?
- saurik 10y ago
  Why do you feel the need to use Xcode (rather than just running the compiler and codesign tools using the build environment of your choice)?
  - adrianotadao 10y ago
    Hum, to be honest, I don't like the Apple development flow. I don't like the Apple developer center, I don't like the Certificates, etc etc. In my case, I need to use XCode to find out the right places to link the react-native lib to my project...
- gempir 10y ago
  Why do you feel it's painful? I've only written a tiny desktop menu bar app with it, but I liked the clean look of it and it didn't feel so cramped like Visual Studio. Maybe I just don't have written with it enough.
  - fstephany 10y ago
    If you work with a large-ish ObjC+Swift project, XCode is quite painful. I regularly lose syntax coloring. Compile errors get stuck and don't disappear when the code is fixed. Refactoring Swift code is non existent. Importing images in the project locks the entire UI thread. Storyboards that are more then a couple of screens take ages to open and edit. SourceKit should help XCode to reason about Swift code but somehow XCode gets lost at least once or twice a day on my machine (MBP 15" i7, 16GB RAM). Android development tools used to suck but since Android Studio 2.0 and the rise of Swift, it is now iOS dev tools that are lagging behind.
ssijak 10y ago
I am waiting for a swift->js compiler and a new explosion of hipster wave of how it is the greatest thing ever, even better than the last weeks hot tech.
- themihai 10y ago
  there is already one. http://www.shiftjs.com/#/home http://www.shiftjs.com/#/home
hubert123 10y ago
Would really be nice if it could offer generic linux binaries... this ubuntu only development approach is quite aggravating. I don't mind a big download, why not just bundle your LLVM changes and package it all in a single download?
skohan 10y ago
Does anyone have a good linux-based swift workflow? I'm starting to experiment with integrating the language in cross-platform projects and I'd love to be less reliant on Xcode.
- letalvoj 10y ago
  I have a question. Why would you use Swift for linux development? Is there a binding to any major UI framework (QT...)?
  - skohan 10y ago
    For now it's mostly just experimentation/personal projects, but I'd like to be able to write web-servers in swift and to use it for image processing. Swift is interoperable with C, so any library with a C interface is freely available to a Swift application.

167 points by okket 10y ago

A week or two ago I updated a fairly large project to 3.1. Not as painful as the 3.0 upgrade by any means, but there were still a fair few warnings about features that will be deprecated in future releases. Dropping support for the initialize() function was probably one of the most prominent. To me that seems like a nice way of doing it - warning developers about approaching changes with a fairly strong warning message, and allowing time for those changes to take place.

slavapestov 10y ago
Most of the new warnings in 3.1 were with things that never should have worked in the first place (some stuff with public declarations referencing private typealiases in their type signatures and things like that). There were also some new warnings added for mixed type arithmetic which is a common source of surprising behavior. The initialize thing is as far as I understand due to a limitation in the Objective C runtime and overriding initialize in Swift never fully worked in the first place. If you feel the 3.0 to 3.1 migration was still too painful from a compatibility perspective, it is not too late to file bugs; Swift 4 will still remain compatible with Swift 3 source so we can make further adjustments to the type checker if needed.

dep_b 10y ago

Hopefully it has support for warnings when formatting strings with optional values: http://stackoverflow.com/questions/42045139/i-want-a-compiler-warning-or-error-when-i-use-a-wrapped-string-in-formatting http://stackoverflow.com/questions/42045139/i-want-a-compile...

jordansmithnz 10y ago
Good news - it does. For me, it fixed a lot of bugs that I had no idea existed. Seems like a pretty easy mistake to make, since third party libraries I use were littered with exactly the same mistake.
- dep_b 10y ago
  Yep it was a really nasty one. Because it used to work differently in Swift 2.x where it would not put Optional() around it in certain circumstances.
  - glhaynes 10y ago
    Interesting, I don't remember noticing it behaving that way. What were the circumstances, if you recall?
    - slavapestov 10y ago
      I think there were differences around calling .description versus .debugDescription when a type is converted to a String, which had some odd behavior with Optional. I think there was an evolution thread about this but you'll have to Google it yourself since I'm on my phone right now :-)
    - dep_b 10y ago
      var someInt: Int! // class parameter // later, in a method let url = "/api/bla/\(someInt)" In Swift 2.x it would simply show the value of someInt. Now it will print Optional. The problem is described in the linked Stack Overflow question as well. I never program like that but there's a ton of people out there that convince the compiler they're going to set that value in time even when it's not set when init is called. Just like some people (including Apple!) use this pattern for setting outlets: IBOutlet var someLabel: UILabel!

misterdata 10y ago

Just installed, compiling a fairly large project gives me "Command failed due to signal: Illegal instruction: 4" without any further information. Smooth...

okket 10y ago
Congratulations, you managed to crash the compiler. Can you please file a bug? https://swift.org/contributing/#reporting-bugs https://swift.org/contributing/#reporting-bugs
- misterdata 10y ago
  Of course, just did. Very surprised that this happens for a 'source compatible' point release of Swift. Especially as this can be triggered with only five fairly simple lines of code. Not good.
  - okket 10y ago
    Thank you!
  - numerlo 10y ago
    Well they are called bugs and they exist in every software. It's not like they did it on purpose.
    - devsquid 10y ago
      Yea, but the Swift compiler is extremely buggy. Plus its gotten buggier with each release.
      - flipgimble 10y ago
        That sounds like you are making engineering decisions by superstition. Unless you have some source of data to back it up, please don't spread your subjective misinformation.
  - 10y ago

akanet 10y ago

Does anyone know where the new Linux binaries are? The release announcement links to https://swift.org/download https://swift.org/download, but I can't actually find the 3.1 binaries anywhere.

vetinari 10y ago
There are neither source releases, nor tags in git repository yet (except the 'swift' repository).
- slavapestov 10y ago
  You can download a 3.1 development snapshot. I'm not involved in preparing the official releases but I'm assuming the Linux 3.1 release will be very close to what is in swift-3.1-branch now. And all the action these days is on the master branch so if you're on Linux and want to help us squash regressions you should periodically test your codebase with master snapshots.
  - vetinari 10y ago
    At this stage, I'm more interested in properly packaging it (for a non-Ubuntu distribution), than compiler development itself. Not having at least tags for the release is very unusual, especially given the title of this article ;). As it is composed from multiple packages, there are too many moving parts than may or may not fit together. It would be great, if there was a tag+source tarball for each release. I'm sure internally there must be something, your colleagues certainly must know, to which commit 'Apple Swift version 3.1 (swiftlang-802.0.48 clang-802.0.38)' maps to.
    - alblue 10y ago
      There is a tag for the release, called swift-3.1-RELEASE: https://github.com/apple/swift/tree/swift-3.1-RELEASE https://github.com/apple/swift/tree/swift-3.1-RELEASE It's not showing up on GitHub's UI nor search for me at present, which may be why it seems like it's missing. You can download a .tgz from GitHub but bear in mind that you have to do the same for each of the nested repositories as well. If you're building it for yourself, it's easier to download the swift-3.1-RELEASE content, and then run 'utils/update-checkout --clone --skip-history --tag swift-3.1-RELEASE' to procure the rest of the repositories. There are a number of bugs to work on Swift packages for RHEL/CentOS: https://bugs.swift.org/browse/SR-100 https://bugs.swift.org/browse/SR-100 https://bugs.swift.org/browse/SR-108 https://bugs.swift.org/browse/SR-108 https://bugs.swift.org/browse/SR-116 https://bugs.swift.org/browse/SR-116 The issues are primarily around those operating systems having too old a version of Clang in their default repositories to be able to bootstrap the newer builds, and the fact that they don't have the blocks runtime available, both of which are used by the Swift runtime.

mixmastamyk 10y ago

Interesting to hear that IBM helped improve the release on Linux, thanks. I may consider it for a project in the future.

pjmlp 10y ago
Yes, IBM is putting some money into supporting Swift, just like they did with Java in the early days. https://developer.ibm.com/swift/ https://developer.ibm.com/swift/ https://developer.ibm.com/swift/kitura/ https://developer.ibm.com/swift/kitura/ https://www.ibm.com/cloud-computing/bluemix/de/swift https://www.ibm.com/cloud-computing/bluemix/de/swift

dilap 10y ago

Used objc a bit; never used swift. Question about this signature: func drop(while predicate: (Self.Iterator.Element) throws -> Bool) rethrows -> Self.SubSequence I take it the "throws" on the type of predicate means it can 'throw/return' an error. Why would you do this? Why not just require your predicate function to be able to process any element? Or I am confused? It seems like the equivalent in Go, for example, would be something like this func drop(seq []T, while func(T) (bool, error)) ([]T, error) which, again, seems like madness. Or am I confused?

mayoff 10y ago
First, why not allow your predicate to throw? Maybe your program will be better structured that way. Second, if you pass a predicate that is not declared `throws`, then the compiler treats `drop(while:)` as if it cannot throw either. This is what `rethrows` means: it makes `drop(while:)` covariant (in terms of throws-ness) with `predicate`.
slavapestov 10y ago
With 'drop' passing a throwing predicate feels a bit esoteric, but consider something like 'map'. Suppose you are mapping over an array of file names and loading each one, which can throw. You would expect the 'map' itself to throw if processing one of the elements throws. You can write higher order functions that only take total functions as arguments and handle errors with an 'Either' type, which is more general but creates boilerplate. Also 'rethrows' is a special keyword that means if you pass in a function that does not throw, the overall operation won't throw either. So mapping over an array of integers to increment each one won't require error handling, since the operation itself cannot fail.
- dilap 10y ago
  Ah, OK, interesting. Thanks for the response.
- Someone 10y ago
  "So mapping over an array of integers to increment each one won't require error handling, since the operation itself cannot fail." Nitpick: in Swift, "since the operation itself cannot fail" isn't correct. The operation will fail on overflow, but it will terminate your application rather than throw.

adomanico 10y ago

Very anecdotal evidence: I work on a fairly large mixed Swift & Objc project and I was expecting a greater decrease in compile times. At first it seemed 'snappier' but starting to notice not much of an improvement. It definitely still feels like making small changes like changing a function name triggers a lot of extra work. I should fire up some benchmarking of Swift 3.1 vs 3.0

slavapestov 10y ago
There are two main sources of slow compile times in Swift -- the expression type checker has exponential in the presence of large numbers of overloads (which unfortunately includes arithmetic expressions and collection literals). The second is what I think you're hitting which is that incremental builds sometimes rebuild too many files because the dependency tracking is overly conservative. There was some work on the expression type checker in 3.1 (string interpolation, casts and a limited "domain shrinking" pass to simplify some arithmetic expressions) but the main focus there was centered on the declaration checker, in particular up the generics implementation to fix lots of crashes and limitations. Both the expression checker and incremental builds should receive more attention going forward though. In the meantime the usual workarounds might help - splitting up your codebase into multiple Swift modules ("targets" in Xcode), and splitting up complex expressions and adding explicit type annotations.
slavapestov 10y ago
Also have you tried enabling precompiled bridging headers? This was added in 3.1 with the goal of speeding up mixed Swift/ObjC builds (by none other than Graydon Hoare), but other than that I don't know much about it.
- adomanico 10y ago
  My understanding was that this was enabled by default
- adomanico 10y ago
  It looks like it was actually disabled before release https://github.com/apple/swift/commit/5b9166ba8098a23e0601aac96ede363dea2484ae https://github.com/apple/swift/commit/5b9166ba8098a23e0601aa...

adrianotadao 10y ago

I like Swift but I hate the Xcode and the Apple tools. Is so painful to code with it. Apple needs to change its entire development flow. Even working with the react-native I need to use Xcode. =l

ryanbertrand 10y ago
Have you tried the JetBrains AppCode IDE?
- adrianotadao 10y ago
  Never, is it a good choice?
saurik 10y ago
Why do you feel the need to use Xcode (rather than just running the compiler and codesign tools using the build environment of your choice)?
- adrianotadao 10y ago
  Hum, to be honest, I don't like the Apple development flow. I don't like the Apple developer center, I don't like the Certificates, etc etc. In my case, I need to use XCode to find out the right places to link the react-native lib to my project...
gempir 10y ago
Why do you feel it's painful? I've only written a tiny desktop menu bar app with it, but I liked the clean look of it and it didn't feel so cramped like Visual Studio. Maybe I just don't have written with it enough.
- fstephany 10y ago
  If you work with a large-ish ObjC+Swift project, XCode is quite painful. I regularly lose syntax coloring. Compile errors get stuck and don't disappear when the code is fixed. Refactoring Swift code is non existent. Importing images in the project locks the entire UI thread. Storyboards that are more then a couple of screens take ages to open and edit. SourceKit should help XCode to reason about Swift code but somehow XCode gets lost at least once or twice a day on my machine (MBP 15" i7, 16GB RAM). Android development tools used to suck but since Android Studio 2.0 and the rise of Swift, it is now iOS dev tools that are lagging behind.

ssijak 10y ago

I am waiting for a swift->js compiler and a new explosion of hipster wave of how it is the greatest thing ever, even better than the last weeks hot tech.

themihai 10y ago
there is already one. http://www.shiftjs.com/#/home http://www.shiftjs.com/#/home

hubert123 10y ago

Would really be nice if it could offer generic linux binaries... this ubuntu only development approach is quite aggravating. I don't mind a big download, why not just bundle your LLVM changes and package it all in a single download?

skohan 10y ago

Does anyone have a good linux-based swift workflow? I'm starting to experiment with integrating the language in cross-platform projects and I'd love to be less reliant on Xcode.

letalvoj 10y ago
I have a question. Why would you use Swift for linux development? Is there a binding to any major UI framework (QT...)?
- skohan 10y ago
  For now it's mostly just experimentation/personal projects, but I'd like to be able to write web-servers in swift and to use it for image processing. Swift is interoperable with C, so any library with a C interface is freely available to a Swift application.