Actually, I feel the complete opposite. It has been great to be able to systematically update APIs over time. Remember, the "grand renaming" is unlike any other refactor. It takes a massive quantity of time to do and Apple needs to gather as much feedback as possible during that work (hence the numerous betas the work has been spread over).
While I sympathize with your exasperation, I'd point out:
— It's a beta of Xcode 8.0, not of Swift 3. AFAIK, there's not even a guarantee that Swift 3 will ship with 8.0 — if the timing doesn't work out, Swift 3 could potentially be released later, in Xcode 8.1 or something.
— It was clearly stated that Swift 3 would be a dramatic change, and anyone who's been following Swift Evolution will know that it's got even more dramatic in recent months. You opted into this when you chose to move your code to Swift 3 syntax. There was no reason to move past Swift 2.2/Xcode 7.3.1 unless it was your intention to embrace change.
As it happens, Swift Evolution has apparently been pretty much frozen in the last 2 weeks. That suggests that the just-released beta 6 might contain a Swift 3.0 that is much closer to what you'd call a beta. Or beta 7 will.
Case in point:
In Xcode's model editor for Core Data, the code generator's Language setting still does not persist, nor do your default target and group selections for code generation. Those bugs were reported several versions ago.
Worse, today, the underlying accessors for properties (as well as any comparisons) no longer work in Beta 6 without painstakingly rolling every value in an NSNumber. So that prompts us devs to go into the model editor and choose Use Scalar Types for properties. That reduces some of the pain, BUT the Use Scalar Types option also does not persist in the model editor. It gets turned back OFF the next time you come back to the editor.
So for apps with large Core Data models, this causes 1000s of lines of code to break. And when you go fix them, Xcode just reverts your changes on you and everything's broken again. It takes almost an hour to go through my model one entity and one property at a time.
THESE are the tool bugs Apple should be focusing on fixing in late Beta. Not renaming APIs and making Swift even harder to use.
>>THESE are the tool bugs Apple should be focusing on fixing in late Beta.
I agree with that part.
>>Not renaming APIs and making Swift even harder to use.
I disagree with that part. From the point of IDE-related tools, Swift is a 3rd-party development, with different people and its own timeline.
Taking a step back, I'd suggest that Swift is a victim of its own success. Based on its language design, pretty much the whole world turned out to be interested in evaluating/adopting Swift to some degree, but the non-Apple world went into severe shock because:
— Swift 1 and 2 without Foundation lacked vast realms of functionality that everyone expected to be provided in some kind of system library.
— Swift 1 and 2 with Foundation were incomprehensible to non-Apple developers, all the way from large concepts down to API naming.
Swift 3 is essentially a response to those shock waves. It makes (well, hopes to make) the Swift environment viable for more people. The amount of change reflects the difference between an Apple-centric coding environment and a nearly-whole-world coding environment. I think this is largely a good thing, in spite of the upheaval it required.
It's fine to break things to evolve, but not fine to break them every week or so, not when you're Xcode.
I can't help but wholehartedly agree with the original poster. I've just ported about 5k lines of code to Swift 3 to try and follow the best practices as evangelised in WWDC, and every beta release means more and more churn and things breaking. Note, that this is not churn between Xcode 7.x and Xcode 8 or Xcode 8.1, but between beta versions of Xcode 8 itself.
I'm not saying the changes to the language are bad, far from it, most changes I've seen in Swift 3 have been for the best and it's only getting better. The problem here is with the churn between beta versions of Xcode, and what that implies to the post-release stability of Xcode's Swift 3 toolchain, not the long-term changes in Swift. Xcode is a development tool and the language used in this tool should not be changing from one beta to the next. In fact the whole point of beta is to shake out bugs, not alter the product itself, as the original poster has pointed out.
The internals, mangement style, and politics inside the Swift open-source project are irrelevant to Xcode as a product from a user's standpoint, and the original poster here is talking about using Xcode, not the open-source Swift language from the command line. It's fantastic that Swift is evolving at such a rapid pace. However, claiming that it's ok for Xcode to be this volatile this late in the release cycle because "Swift is a 3rd party project with its own schedule" is just passing the buck. So are Clang and WebKit but I'm sure the Clang compiler doesn't change the arguments it accepts between Xcode beta versions either. Instead Xcode picks a Clang version and sticks with it, at least during a beta!
As for the Swift 2 legacy mode, Xcode 8 was demoed on WWDC as a Swift 3 environment. All the slides and lectures were on Swift 3, weight was given the API Design Guidelines talk, developers were encouraged to start projects in Swift 3 or port existig codebases to it. Now that Xcode is in beta syntax ought not be changing weekly this late in its release cycle - unless the implication is that we should ignore the WWDC information and use Xcode in legacy mode in Swift 2, or avoid Swift altogether, as it would seem that sometime after WWDC it got deprecated to a volatile work-in-progress language? I hope this is not the case.
If the Swift project internally likes to have its own experimental or "community" Swift that changes daily, that is fine, and in fact the whole point of good open-source projects is to be this agile and dynamic. The Swift open source project is working perfectly. The problem here is Xcode release engineering letting all the "hotness" in between Xcode beta builds.
Xcode should ship with stable releases of the Swift project between *Xcode* versions, not between *beta* versions. If the intent was to be a Swift 2 IDE with an optional experimental "community swift 3 preview mode" then this should have been made clear in WWDC, the release notes, or somewhere with some visibility, but I'm pretty sure THAT was the point of the "Toolchains" menu, and not the base Xcode 8.0 toolchain itself that we as Apple-platform developers do actual work on.
Again, it's fantastic to see Swift moving so fast, but at some point 3.0 should freeze (as the original poster suggests, the end of the Xcode 8 alpha would have been a good cut-off point!), bugs fixed, shiped with Xcode 8, and the new and exciting stuff (that breaks things) should start happening for 3.1, 3.2, etc. which can then be picked up by Xcode 8.1, 8.2, etc. Isn't that release engineering 101?
I hope this rant makes some sense, apologies for the length.
I agree with you. What I worry about is introducing more and more bugs with every release of the next beta. All of these constant changes between beta versions will introduce unnecessary bugs making stable code less stable.
I was surprised that Xcode 8, beta 6 came out so quickly after beta 5. After switching over to beta 6, I was shocked to find that my project had over 120 errrors. At first, I thought it must be Xcode's problem. And then I read on. I'm developing using Swift 3. I've gone down the path. I finally got the bugs fixed late last night. I think it would be nice if we knew a date when Swift 3 will be finalized, but I don't think we'll be given that information, nor do I think anybody knows. I guess we'll just have to ride the storm out.
I have to echo the sentiments of Scenario and ptsochantaris. In fact, I've come close to posting something similar myself several times in the last few weeks.
Right now, developing with Swift 3 in Xcode 8 feels like working on quicksand and I spend more time searching online for information explaining the current syntax, than I spend actually programming. Everyone expects bugs in a beta, that's the risk you take working with a development tool in beta. What you do not expect is wholesale changes in command syntax and structure, and not just once, but several times, nevermind the flip-flopping fiasco with NS prefixes. I've used a number of beta's in recent years and I've never seen these kinds of changes in an Xcode beta before. It would be more palatable if there was adequate documentation easily available explaining the changes, but if there is I can't seem to find it. Thankfully with beta 6 there seems to be more detailed information in the release notes, but since I haven't switched to beta 6 yet it remains to be seen how good that information is.
QuincyMorris says that Xcode 8 isn't a beta of Swift 3 and he's right, it's an alpha. Nothing else explains the experimental nature of the changes being made. He also says that Swift 3 may not ship with Xcode 8.0. If that's correct then it's most unfair not tell us that. I don't have a problem with Swift 3 being a dramatic change from Swift 2, provided the changes aren't frivolous and improve the language for the better, AND provided that they aren't foisted on us piecemeal, every few weeks. Looking at some of the changes makes me wonder if Apple even knows what it wants the language to be. It's like watching a painter constantly painting and unpainting bits of the canvas in a vain effort to make it perfect. Was it Voltaire who said: "Perfect is the enemy of good"?
ptsochantaris is right on the money when he says:
>>> Xcode should ship with stable releases of the Swift project between *Xcode* versions, not between *beta* versions. If the intent was to be a Swift 2 IDE with an optional experimental "community swift 3 preview mode" then this should have been made clear in WWDC, the release notes, or somewhere with some visibility, but I'm pretty sure THAT was the point of the "Toolchains" menu, and not the base Xcode 8.0 toolchain itself that we as Apple-platform developers do actual work on.
What's really getting to me is all the flip-flopping:
- remove NS prefixes
- NSDecimalNumber: .notANumber -> .notA
- first argument labels for all function
- add some NS prefixes back in
- NSDecimalNumber: .notA -> .notANumber
- omit first argument labels for some functions
Is there any link to the rationale for the NS appearing and dissapearing? I'm also frustrated at seemingly losing the impicit conversion of Date to NSDate, Decimal to NSDecimal, and especially Int to NSNumber. Where is that explained?
Implicit bridging has now been completely removed SE-0072. It is in the release notes but still came as a big change especially when using Core Data as I am. I've had to make a lot of code changes going into beta 6, most of them due to this change so it's been quite painful. I've still yet to find solutions for some compile errors!
Folks, the general topic of this thread is way above my pay grade so I’m not going to respond here. However, if you have specific issues getting your code to compile and run with the latest Xcode beta you should feel free to start a new thread with the details and I’ll respond there.
Share and Enjoy
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
Thanks. I think the two biggest 'issues' are the removal of implicit bridging and AnyObject to Any. The compiler warnings and errors are not helping because the messages are inconsistent. What you often find is something like this function does not override from a subclass and you then have to hunt through to find what the funtion has become. Examples being prepare(for segue: or observeValue(forKeyPath keyPath:
Quinn, if this feedback is above your pay grade then you need a raise and a promotion, because you've been around long enough to have more influence than that on a team as important as the Swift team.
For the expected quality of software in a third-generation project in late Beta, Swift 3 has become a trainwreck of Microsoftian proportions--at least in terms of process and expectation. Many of us devs are spending 90% of our time not developing our app, but babysitting Swift and trying to understand so many unvetted changes. That's fine if you're working on salary but for many of us, time is money.
This is made all the more difficult by not having a stable language spec, adequate documentation, code samples or working look-ups in Xcode for two years now. We're being treated like lab monkeys during late Beta as I said above. As others have said, it feels like we're developing in quicksand. The lack of attention to glaring bugs in the editor and the tool chain is deeply concerning.
I can't even build without segmentation fault 11's half the time, because Swift's type engine still can't deal with the complexity of larger, real-world code bases or literal declarations whose types should be easily inferred. That bug has existed since the first Swift 1.0 Betas. Typically the only way to work around these bugs is to proceed very cautiously, unit test the heck out of your app, use source control bisection to isolate changes that are too complex, and then find ways to break them up into simpler expressions.
The error messages we get are still sadistic. Many of them are nonsense, or are not actionable because they use terminology that only compiler engineers know. And many of them are downright misleading. A Fix-It will typically recommend a change, then change its mind, and then add some other suggestion a few seconds after you've already moved on. This is complicated by all the UI lag in the Xcode editor, and the pile of popup windows and mis-highlighted lines of code. Sometimes a batch of errors won't get reported, your app will run, and then the next time you build those errors suddenly get reported. How does that happen and how can we trust such an IDE?
Many of the recent Fix-Its are just renames, so why not just do them if they're straightforward? Instead, we get a Fix All in Scope command that still crashes Xcode if you dare use it. And here we are on Swift 3 and there is still no Refactor support at least for renaming? How is that acceptable in a modern IDE?
If you've banked on Core Data for your apps in the past, you're basically living a nightmare if you chose to migrate to Swift. Xcode decided to obviate mogenerator without fully understanding how it was used or even testing the crappy Core Data accessor code generated by Xcode. In Beta 5, we got OrderedSet that wouldn't compile. And then in Beta 6 we were told it was fixed but all they did was rename that string back to NSOrderedSet, and without taking the extra step to finally make to-many relationships mutable or properly typed. The underlying accessor code not only crashes at runtime, but we can't even see what that code is trying to do because it's hidden from our project. And we're supposed to believe these bugs will all get fixed in one or two more Betas?
Generally speaking, I think open-sourcing Swift has had predictable results. It has made Swift even more difficult to use with Cocoa as APIs diverge and get generalized. We could all cite 100s of examples where Swift code is far more complex or obtuse than Objective-C. And that especially includes the basics, like all the common things you need to do with strings, arrays, dictionaries and enums that require far more code and cryptic symbols now in Swift.
The bottom line is that for all the advances in Swift, as a language it utterly fails to achieve its original, primary goal which was to be easier to learn and use. It's not either of those, and its instability makes it a timesuck. Instead of building a modern compiler that understands developers, we are now expected to think like a compiler. Just look at how much of a typical Swift app's code is made up of optionals and typecasting. That does NOT make an app demonstrably safer to run or easier to maintain. Instead, you can actually measure the time and money lost in productivity.
Sorry for my annual rant, but this is the point each year where the Swift team needs to be reminded to get their act together. Please Alpha test somewhere else.