I don't mind either. And I have a commercial Mac application written 98% in Swift to maintain.
Now the risks were known when we green fielded the project. It was certain that Swift syntax and the frameworks would change in the future. But the time we saved in development makes up many times for the maintenance burden now.
Luckily refactoring strongly static typed code is not that of a fiasco :)
Yes, not really a problem in that case. But let's not forget that this release also contains nearly 50 other source breaking swift-evolution proposals (full changelog here: https://github.com/apple/swift/blob/master/CHANGELOG.md).
But one of the things I like about how the language is begin developed is that everyone involved is aware that having the language in a constant state of flux is painful, and try to provide useful warning messages (or wizards if you use XCode) for those that will need to update their code to a newer release sooner or later.
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/
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 latter would be much easier to think about like foobar == .someEnum but it gets mucked up.
I don't understand why these can't be streamlined into something like this:
if let a = b && let d == f && foobar == .someEnum
//you can't do any of this
Instead, you have to use "where" and commas rather than && in some places, the whole thing is a much greater cognitive overload than it should be for such a fundamental task in any language.
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.
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.
[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...
> 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.
I look forward to using Swift in a couple of years when it is all stable. It looks great. Thanks to those of you using it now and contributing to its improvement.
I don't want to have to ship apps containing the entire runtime. I'm waiting for the stable ABI.
As well, I'm happy to let the keen early-adopters be the guinea pigs. Xcode 8 only came out today. If you have production apps, it's madness to upgrade on day one. I'll wait a few weeks/months for the remaining bugs to shake out.
Don't get me wrong I'm very pro-Swift. But I'm also mindful of my time and sanity. Switching to a new language sure sounds fun, but not exactly productive (in the short term). When I do switch, I want everything to be rock solid, stable, all the tools, docs and everything.
But I have created a couple of toy projects in Swift, and I'm very excited to start using it properly in a year or two.
I've only recently gotten into iOS development and the state of XCode amazes me. It's awful. Frequent crashes, disappearing tests, syntax highlight shutting down... it really makes me wish there were an alternative.
You can buy AppCode. It's based on IntelliJ, so if you are used to taht it's great. But it's not perfect and I usually have both IDEs open when working on iOS (in aprticular, running and debugging are nicer from XCode. I write my code in AppCode and run it from XCode).
There's nothing stopping you from using one. The great thing about OSX is that you can get to the command line just like Linux and use Emacs or Vim. Or even GUI IDEs like Geany if that's what you want.
A lot of this is worse for Swift than it is for Objective-C. Still, I do find it weird that such a mature product (roots going back decades, really) is still so shaky in fundamental areas. In many ways it has actually regressed since e.g. version 3.
I found versions 5 and 6 really buggy. 7 got better but I am waiting a while before going to 8. It is just too risky to upgrade so soon, given its years of buggy releases. It's poor.
"The entire runtime " is about 6 MB, and its inclusion in your app is completely transparent. (Admittedly I'm on the Mac, and there's undoubtedly more of an impact on iOS.)
Swift 3.0 is really nice but I backtracked out of Xcode 8.0 for now. I am used to Xcode but this one still vomits Apple internal debug messages into the console, that's really too rough for me. I'll wait for the .01 or the .1 before upgrading all my projects.
Funny thing is I downloaded one of the first if not the first beta of Xcode 8 and it already migrated my projects flawlessly (where possible). It's all the other stuff that's broken.
there's a settings flag you can add to stop those internal debug messages, which I believe started in the XCode 8 Beta. It is pretty annoying that this not clearly mentioned or toggle-able in the UI
Try this plugin[1] which will unsign Xcode and allows older plugins to work.
I also encourage you to file a radar [2] to let Apple know you're not pleased about them killing a thriving plugin ecosystem. Yes, I know there's a new plugin API but it's so crippled that 90% of the plugins on Alcatraz couldn't possibly move to it. If enough of us complain maybe they will listen.
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 project has hundreds of syntax errors due to renamed methods, not that hard to fix, but not sure if they'll still run the same...
So this is a major upgrade to your project - do it when you have spare time to waste.
In the meantime, I'm thinking of reverting to Xcode 7.3 and running the two versions side by side... Is that possible ?
> 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.
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.
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.
> This created havoc in Python. Hopefully it won't happen here.
There are big differences though:
* Python had 15 years of source-compatibility before the switch, Swift has 1 year and a history of source-incompatibility (Swift 2 was not source-compatible with Swift 1)
* Python had a fair amount of semantic-incompatibility
* Python doesn't have a (heavy) compiler backing it up making source and semantic incompatibilities runtime issues your program bashes its face in rather than cascading compilation failures
> It won't happen because Apple won't give you the option.
What won't happen, havoc in the ecosystem? How is Apple relevant?
> Swift 3.x has a large amount of syntax changes.
Yes?
> The compiler helps with the refactoring but it's still work.
That's not what I'm talking about. A bit of drudge work is fine, the issue of the Python transition is that you get usually hard to debug runtime failures down the line, possibly for a long, long time. With Swift, I assume the compiler just keeps complaining until you've converted everything more or less properly, you may have a few nits but you don't keep finding new breakages.
What won't happen is that Apple won't let people build against old versions of Swift. We'll all be on 3.x soon.
I have no idea how hard the conversion of a large Python 2 to 3 project is. My projects were small and I had no troubles. At any rate 2020 will be here soon and 2.x support will end. All Swift users will be on 6.x by then.
As per the blog [0], you can expect a lot to break.
Swift 3 is a source-breaking release, largely due to the
changes in SE-0005 and SE-0006. These changes not only impact
the names of the Standard Library APIs, but also completely
change how Objective-C APIs (particularly from Cocoa) import
into Swift. Many of the changes are largely mechanical, but
they can be numerous in a typical Swift project.
To help with moving to Swift 3, Xcode 8.0 contains a code
migrator that can automatically handle many of the need source
changes. There is also a migration guide available to guide you
through many of the changes — especially through the ones that
are less mechanical and require more direct scrutiny.
Until now Swift has not promised source compatibility so the developers should be ready to rewrite their code for new versions. I would not be surprised if Swift 2.3 support were dropped in the next version of XCode completely.
The migration tools are quite good though so going from 2.2 to 3.0 directly should not be much of a problem.
I think that in Python the problem was/is that the 2.x was already a massively used and mature language when the 3 came out.
External librairies can also support the migration by providing "fix-its" which helps the compiler display an helpful message whenever a Swift 2-era line has not been updated to Swift 3 (see for example this PR: https://github.com/groue/GRDB.swift/pull/114)
The conversion tools failed pretty badly in my case. I had to do a ton of manual fixes. There are also still a lot of libraries out there that haven't updated yet so unfortunately I'm holding off on updating for now.
For us it worked quite fine for macOS but not for iOS targets. It also changed the function names for a lot @IBAction functions but did not update the connection in the interface builder. So now I have to a lot of testing to make sure all buttons work.
Still I have to admit it shows quite courage (get it?) to change so many things but naming is important and I see it positively. Only if Apple would use version numbers for Swift that would fit to the state, if you have that kind of fast update cycle and that many breaking changes a version number below 1.0 would have been better for Swift 1 and 2.
It has also created havoc in the Swift world. Suddenly all existing Swift code is broken. The migration tool is supposed to take care of most of this for you but my experience has been that it misses a lot of things and upgrading requires many manual fixes. Of course every Swift library in existence also needs to be updated so your changes of a smooth migration right now are slim.
Apple has the resources to push this through and developers don't really have much choice so I don't expect this to become another Python 3 fiasco but this really should be the last time Apple breaks so much code just to clean up the syntax a bit.
It makes a lot of sense, though. Like many new languages Swift was invented hastily and without much care with the main goal of locking in developers and preventing cross-platform development. If Apple made major releases backwards-compatible, this would invariably turn the language into a big mess in the long run.
This way, the language can evolve into a fine language with many features from Algol-68 and the usual semi-popular C-ish syntax, and Apple can continue to ensure that developers have to maintain a separate codebase for their "apps" that is useless anywhere else.
Swift was started in July 2010 by Chris Lattner[1] and it was publicly announced by Apple in June 2014 (and the 1.0 release was September 2014). Spending 4 years on it and including other programming language experts to contribute to it doesn't seem like a reckless and thoughtless release. What it shows is that even if a group spends years on it, they will still get a lot of things wrong. Same for C# that was (formally) started in January 1999 and not publicly released until December 2002. Even though that language also had 4 years of gestation by smart people, they still got generics and a bunch of other things wrong (e.g. terrible name of "destructors" for the concept of finalizers.)
I didn't realize that programmers thought Swift was created in a hurry like Brendan Eich's "10 days" to design Livescript/Javascript for Netscape Navigator[2]
I like Swift but it really was released too early. There were fundamental problems with the tooling for a long long time after the first release and there has been a lot of churn in the syntax even after the tooling started to settle down.
Designing a language like Swift is hard and it's not reasonable to expect them to get everything right on the first try but I do think it would have benefitted from a lot more dogfooding before they started pushing it on developers.
>There were fundamental problems with the tooling for a long long time after the first release
I was speaking of the language syntax and specification separately from the "tooling." Virtually every language has terrible tooling when it's first released. (e.g. Golang doesn't have a real debugger, Rust build chain on Windows is suboptimal, etc). Yes, Apple's Xcode and Playgrounds were extremely buggy with Swift. Given decades of computing history, it's unfortunate that bugs are to be expected of new programming languages.
There are very few languages that emphasize tooling from the very start. Examples that come to mind would be 4GL type languages (SAP ABAP, Powerbuilder) because those proprietary languages often force you to work inside of their GUI editors. Smalltalk might be another example.
This is short-changing the Swift team on a lot of axes, but you're also wrong about the lack of eventual compatibility:
> For Swift 4, the primary goals are to deliver on the promise
> of source stability from 3.0 on, and to provide ABI stability
> for the standard library.
One of the features of Swift is being cross platform. A good 20% of the page that this post links to is talking about their cross platform progress for linux and windows. https://swift.org/about/#swiftorg-and-open-source
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.
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.
> " 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."
MS have made plenty of big changes recently, .NET Core being a prime example.
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.
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
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.
We should all be so lucky that some other languages are willing to break backwards compatibility. Even C++ gurus like Scott Myers advocate that language finally breaking source compatibility [0]. Often, breaking compatibility is the only way to make a language better.
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.
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.
Holding off on learning much more Swift for now, until things stabilize and stuff stops breaking. Its not much fun to go back to learn some Swift only to discover things have changed since last time ..
No need to hold off - now is actually the time to start learning Swift, as it's taking off. If you've written existing code, it will take you minor effort to translate the code (in most cases) and you can also use the code migrator tool.
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"