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

Swift 3.0 Released

swift.org

Post reply on HN
Print view View original

71–80 of 95 posts

Re: Swift 3.0 Released

#71

Post by knocte »

awzurn wrote: 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.

It's a matter of taste.

As for me, that I tinkle more with .NET, I see their (Swift's) grass greener in the fact that they are not afraid of making breaking changes if they truly benefit the platform, something which I don't see MS doing anytime soon.

Re: Swift 3.0 Released

#72

Post by masklinn »

oblio wrote: post #33
thomasahle wrote: post #23

Wow, they've basically renamed the entire Standard Library, see the changeset: https://github.com/apple/swift-evolution/blob/master/proposa... Not that I mind though. This kind of thing should be easy to auto refactor.

This usually madness for production projects, unless you're Apple (or Microsoft in the 90s). But I wish Python 3 did the same with its libraries.

Python 3 did implement pretty significant library changes, though mostly organisational (namespace restructuring, merging of C accelerator modules, renamings, removal of deprecated modules, …): https://www.python.org/dev/peps/pep-3108/

Re: Swift 3.0 Released

#73

Post by unknowingone »

nicky0 wrote: post #58
unknowingone wrote: post #57

How can I get Swift 3.0 going on my Mac if I don't want to upgrade from Mavericks?

With great difficulty.

I only use the command line and have no use for Xcode. With LLVM or GCC I can install as many versions as I want side by side - not the case for Swift. Lame.

Re: Swift 3.0 Released

#74

Post by hellofunk »

masklinn wrote: post #65
hellofunk wrote: post #59

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…

> you can write "foobar == .someEnum" if you've defined "==" for your enum type

Why wouldn't enums be equatable by default? Why rely on a user implementation of ==? Enums, even with associated data, are rather obvious values, aren't they?

Re: Swift 3.0 Released

#75

Post by justsaysmthng »

mrsteveman1 wrote: post #56
justsaysmthng wrote: post #50

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.

Tried that, but it seems the build setting now needs an explicit SWIFT_VERSION configured .. And carthage dependencies don't have that so the build fails.

Basically, I couldn't get my carthage dependencies to compile with Swift 2.3, so I went the Swift3 route, which now, after 10 hours wasted, was such a bad idea!

Appstore was bugging me to update Xcode so I caved in and now I'm stuck with a project that doesn't build and the deadline approaching fast. Such a useless waste of time.

Re: Swift 3.0 Released

#77

Post by masklinn »

hellofunk wrote: post #74
masklinn wrote: post #65

Earlier quoted context omitted.

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…

> you can write "foobar == .someEnum" if you've defined "==" for your enum type Why wouldn't enums be equatable by default? Why rely on a user implementation of ==? Enums, even with associated data, are rather obvious values, aren't they?

> Enums, even with associated data, are rather obvious values, aren't they?

Associated data can be completely arbitrary (and thus possibly not equatable), I expect the designers would rather people use pattern matching instead of the more error-prone boolean constructs, and likely they don't want to add "unnecessary" capabilities so if the developer don't need equatable enums there's no reason to make them and developers can ask for it when they need it.

Rust makes the same choice, so does haskell, though in both enum/data equality is just a derive/deriving away.

Re: Swift 3.0 Released

#78

Post by jeffdavis »

skybrian wrote: post #76

Interesting that they dropped curried functions. Why do functional programmers seem to like it so much and mainstream programmers don't care?

I've always found it annoying because it only works if you want to bind the first argument. If you want to bind the second, you have to do something else.

Disclaimer: not an expert on this subject.

Re: Swift 3.0 Released

#79

Post by Manishearth »

leshow wrote: post #46

Every time I see swift, it's crazy how much they've 'borrowed' from rust. The language looks almost identical

I don't think swift has borrowed much from Rust.

Rather, both are borrowing from older functional languages. These features are relatively new for procedural languages so it seems like Swift borrowed from Rust, but both have borrowed these features from other languages.

Rust did borrow `if let` from Swift (might have existed in other languages, but Swift is where the idea came from). I'm sure there are a few features swift has borrowed from Rust, but not many.

And it's not a bad thing to borrow! (As a Rustacean) I'm happy that Swift is similar to Rust. One of the problems with Rust is the learning curve for folks coming from other languages. With more languages similar to Rust, this is less of an issue. Swift in particular is set up to be used a lot since Apple is pushing it in its ecosystem, which is great.

Re: Swift 3.0 Released

#80

Post by mattnewton »

hellofunk wrote: post #59

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…

I don't agree - case 2 and 3 aren't returning boolean values, they are matching on a pattern. Perhaps using the if keyword was a mistake there, but the commas and equal sign aren't. I think using the && and == syntax is strange when you aren't comparing 2 boolean values.
Post reply on HN