Live data from Hacker News

Swift 3.0 Released

swift.org

61–70 of 95 posts

Re: Swift 3.0 Released

#61

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.

Yes, this is what Swift 2.3 is for.

Re: Swift 3.0 Released

#62
post #60
post #49

Can'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.

What is the point of making it a major release then except for marketing?

Re: Swift 3.0 Released

#63
I 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 serious bugs and enhancements.

If 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

#64
post #63

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

The only thing better than bikeshedding about minor language features is bikeshedding about the language evolution process...

Re: Swift 3.0 Released

#65

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

Your cases 2 and 3 are pattern matches. It's perfectly fine to use regular equality with optionals (case 2) or enums (case 3), but in that case you're not matching a pattern you're comparing two specific values, and you need the types to be equatable[0] (enums aren't by default, though optionals are if they contain an equatable value).

* 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

#66
post #63

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

The renaming of flatten to joined was a last-minute proposal, and it wasn't even implemented by someone of Swift's core team. I don't think it distracted the team much at all.

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

#67

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

Yes. But everyone cares about their code base which they have today not after what they are going to do in 10yrs. An asteroid could wipe us all tomorrow. So I'm definitely worried about reworking stuff that I already wrote.

Re: Swift 3.0 Released

#68
Does this release include a cross-platform Foundations library?

https://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

#69
Most of the API's are changed. Will need to migrate the code base from swift 2.3 to swift 3. Tedious work. But what I liked about the swift 3 API change was the swifitification of the GCD API. I liked it
Post reply on HN