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
Swift 3.1 Released
31–40 of 71 posts
Re: Swift 3.1 Released
#32I 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
Have you tried the JetBrains AppCode IDE?
Re: Swift 3.1 Released
#33I 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
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)?
Re: Swift 3.1 Released
#34Used 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…
The key is the `rethrows` keyword, which allows the compiler to conditionally enforce error handling based on the signature of the given closure.
The equivalent Go code would then (presumably) be these two methods:
func drop(seq []T, while func(T) (bool)) ([]T)
func dropWithError(seq []T, while func(T) (bool, error)) ([]T, error)
If you pass in a closure that does not throw then compiler will assume that `drop()` does not throw.
Re: Swift 3.1 Released
#35Used 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 bu…
Ah, OK, interesting. Thanks for the response.
Re: Swift 3.1 Released
#36Very 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.
My understanding was that this was enabled by default
Re: Swift 3.1 Released
#37I 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
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.
Re: Swift 3.1 Released
#38Very 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.
It looks like it was actually disabled before release
https://github.com/apple/swift/commit/5b9166ba8098a23e0601aa...
Re: Swift 3.1 Released
#39Very 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
Upon further inspection they disabled pre compiled bridging by default before release
https://github.com/apple/swift/commit/5b9166ba8098a23e0601aa...
After turning it on compilation speed seemed to improve immensely
Re: Swift 3.1 Released
#40Used 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 bu…
"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.