If you're thinking of updating to Xcode 8, hoping that your project will 'just build', don't get your hopes too high. I've already spent all day fixing, updating, searching around for all kinds of errors that the build system throws at me. It also required me to update the project dependencies to their latest versions which support swift 3/xcode 8. Some dependencies (like SwiftBond 5) have changed a lot and now my pr…
> In the meantime, I'm thinking of reverting to Xcode 7.3 and running the two versions side by side... Is that possible ? I think you're probably better off just keeping Xcode 8 by itself, but use Swift 2.3 for projects if you need to. There are very very few differences between 2.2 and 2.3, converting existing code over is much faster than 2.2 -> 3.0.
Swift 3.0 Released
61–70 of 95 posts
Re: Swift 3.0 Released
#62Can't wait for the day when they're done deciding to only make major releases every year, and actually settle on a common syntax and platform for the language, will be great not having to worry about my source code blowing up... ... then again, seeing some actual refactor support in Xcode would be pretty great too, but you can't wish for too much at once.
A major release doesn't necessarily have any breaking changes. Swift 4 will contain some breaking changes for sure, but Swift 5 might not.
Re: Swift 3.0 Released
#63If Swift really wants to become successful, they need to work on bigger picture things like fixing breaking regressions, planning full reflection, built-in async instead of bikeshedding about array methods. I understand they want a non-breaking API from 3.0, but everyone isn't always going to be happy; and changing small functions for the vocal minority is not the correct path forward.
A list of 3.0 regressions: https://bugs.swift.org/browse/SR-2603?jql=labels%20%3D%203.0... Flatten rename proposal: https://github.com/apple/swift-evolution/blob/master/proposa...
Re: Swift 3.0 Released
#64I really wish Swift releases were not pinned to Apple releases. Swift 3 introduced several regressions and instead of prioritizing some serious regressions, they focused on swift evolution proposals. For example, one accepted proposal renamed the common array _flatten_ method to _joined_ because it aligned one use case. Granted this is low hanging fruit, but a whole bunch of low hanging fruit takes time away from ser…
Re: Swift 3.0 Released
#65One thing I never understood about Swift and that I don't think is addressed in Swift 3 is the widespread inconsistency with simple 'if' statements. There are at least three incompatible ways to think about 'if' syntax in Swift: if foo == 1 && bar ==2 //normal, from other languages if let somevar = foo, let anothervar = bar //note, must use a comma rather than && if case .someEnum = foobar //cannot use == ! That latt…
* you can write "foobar == .someEnum" if you've defined "==" for your enum type (in Rust that's a deriving(Eq) away, sadly Swift doesn't seem to have deriving):
// requires conforming to Equatable, and implementing
// requires func ==(a: Foo, b: Foo) -> Bool somewhere
// if the enum has associated data[1]
let v = Foo.Bar;
if v == .Bar {
print("ok")
}
you can also do that with optionals by default: let w = Optional.some(3)
if w == .some(4) {
print("ok")
}
* `let a = b && thing` doesn't make sense because `let a = b` is not a boolean value it's a pattern match. That's why you have a separate guard (the where) and have to write `let a = b where thing`, this is what happens in pretty much every language with pattern-matching (though syntax may vary)* `let d == f` makes no sense whatsoever, though as previously noted `f == .some(d)` works
* you can compose `if case` and `if let` in, since both are pattern matches, `if case .Bar = v, let b = w` works fine
If you're getting lost with that, use the regular `if` for boolean stuff, and a full `switch` for all patterns. There, I fixed it.
That aside, I do agree Swift's syntax is convoluted and complex. Part of that comes from `if let` being special-cased to optionals, which is convenient when you're working specifically with optionals but means a separate syntax for other enums.
On the other hand, most languages with pattern-matching don't provided a "conditional-ish" version, Haskell's `if` works solely on booleans, if you want to work with patterns you have to break out the full `case`. Rust lifted `if let` from Swift (with different semantics) because it was such a neat idea.
[0] http://www.andrewcbancroft.com/2015/07/01/every-swift-value-...
[1] for trivial enums (no associated data, though they can have a rawValue), you can just `enum Foo: Equatable` and it'll get a proper implementation; for the rest you have to implement == yourself: http://www.jessesquires.com/swift-enumerations-and-equatable...
Re: Swift 3.0 Released
#66I really wish Swift releases were not pinned to Apple releases. Swift 3 introduced several regressions and instead of prioritizing some serious regressions, they focused on swift evolution proposals. For example, one accepted proposal renamed the common array _flatten_ method to _joined_ because it aligned one use case. Granted this is low hanging fruit, but a whole bunch of low hanging fruit takes time away from ser…
Also, breaking changes such as this one were a lot easier to make in Swift 3 than in a later version.
Re: Swift 3.0 Released
#67BREAKING again? Demotivating a lot.
Swift is a young language. That it breaks some things now means we won't be stuck with its early mistakes forever in ten years.
Re: Swift 3.0 Released
#68https://github.com/apple/swift-corelibs-foundation/blob/mast... says they intend it to be part of Swift 3.0, but https://github.com/apple/swift-corelibs-foundation/blob/mast... still lists a lot of classes as "Incomplete" or "Unimplemented"
Re: Swift 3.0 Released
#69Re: Swift 3.0 Released
#70"Official binaries for Ubuntu 14.04 and Ubuntu 15.10..." I am surprised they don't support the latest Ubuntu with official binaries?