Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift 3.1 Released

swift.org

Post reply on HN
Print view View original

21–30 of 71 posts

Re: Swift 3.1 Released

#21

Post by dilap »

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?

Re: Swift 3.1 Released

#22

Post by adomanico »

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

Re: Swift 3.1 Released

#23

Post by slavapestov »

adomanico wrote: post #22

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

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.

Re: Swift 3.1 Released

#24

Post by mayoff »

dilap wrote: post #21

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, wo…

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`.

Re: Swift 3.1 Released

#25

Post by slavapestov »

dilap wrote: post #21

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, wo…

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.

Re: Swift 3.1 Released

#26

Post by [deleted] »

dilap wrote: post #21

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, wo…

[deleted]

Re: Swift 3.1 Released

#27

Post by slavapestov »

adomanico wrote: post #22

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

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.

Re: Swift 3.1 Released

#28

Post by slavapestov »

glhaynes wrote: post #13
dep_b wrote: post #8

Earlier quoted context omitted.

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.

Interesting, I don't remember noticing it behaving that way. What were the circumstances, if you recall?

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 :-)

Re: Swift 3.1 Released

#29

Post by slavapestov »

vetinari wrote: post #18
akanet wrote: post #16

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

There are neither source releases, nor tags in git repository yet (except the 'swift' repository).

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.

Re: Swift 3.1 Released

#30

Post by slavapestov »

jordansmithnz wrote: post #2

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 messa…

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.

Post reply on HN