Chris Lattner writes:
Hi Everyone,
As we get deeper into the Swift 3 release cycle, we’re beginning to have a more precise understanding about what the release will shape up to be. Ted posted details of the Swift 3 release process last week and I just updated the main swift-evolution README.md file with some updated details about the goals of Swift 3.
This release is shaping up to be a really phenomenal release that will redefine the feel of Swift and make a major leap towards maturing the Swift language and development experience. We have had a focus on getting to source stability, with the forward-looking goal of making Swift 4 as source compatible with Swift 3 as we can reasonably accomplish. It tackled API naming head on (which is one of the hardest problems in computer science [1]), made major improvements to the consistency and feel of the language, and has several nice across the board additions.
That said, it is also clear at this point that some of the loftier goals that we started out with aren’t going to fit into the release – including some of the most important generics features needed in order to lock down the ABI of the standard library. As such, the generics and ABI stability goals will roll into a future release of Swift, where I expect them to be the highest priority features to get done.
I expect discussion and planning for Swift 3.x and Swift 4 to start sometime around August of this year. Until then, it is very important that we as a community stay focused on the goals of Swift 3: I’d really prefer us all to resist the urge to discuss major blue sky features for future releases. We would also like to put a significant amount of effort into bug fixing and quality refinements as well, which means that the core team will be proactively deferring evolution proposals to later releases that don’t align with the Swift 3 goals, especially those that are strictly additive.
Thank you for all of the amazing community that has developed on this list, it is great to work with you all! Let us know if you have any questions,
-Chris
[1] It is well known that the two hard problems in Computer Science are naming, cache invalidation, and off-by-one errors.
Like my coverage of Swift news? Consider buying a book or two to help support the blog. Thanks!
16 Comments
So Apple is destroying Swift. Swift 3 isn’t even out and they already talking about 4 – this is crazy.
Language design requires planning in advance.
I don’t see how this announcement remotely implies that Apple is “destroying” Swift.
It’s a major disappointment that the language has existed for two years and yet you can’t guarantee that code written yesterday will still work with a version of the standard library released tomorrow.
I’m really concerned that Swift is going to get a reputation for breaking code with every release or point release. In production environments, people like to write the code once, debug and test it and then leave it alone. They do not want to have to go back and fix all the new warnings/errors every six months or year because that involves a full test / release cycle for no reason other than (for example) somebody disliked post-increment operators.
Compare the Swift-Evolution goals for Swift 3 to how they were before Chris changed them. They used to be Stable ABI; Resilience; Portability; type system clean up and documentation; complete generics; focus and refine the language; API design guidelines. Only two of those goals will be met – the last two.
Judged by its original goals, the Swift 3 release is a failure. Clearly we lost focus on what we were trying to achieve and we need to understand why. Unfortunately, Chris’s relocation of the goalposts is likely to obscure the fact of the failure and probably the same mistakes will be repeated for Swift 4. It’s melodramatic to say that Apple have destroyed the language, but we should certainly be concerned for its future.
I don’t want to lay the blame entirely at Apple’s door. If the community (i.e. us) had spent as much time focussing on the stability of the ABI as it has on whether we should allow training commas in parameter lists or what multiline strings look like or C style for loops, we would probably have a solid binary ABI now.
The alternative is to let the language become stagnant. I like the rapid evolutionary pace of Swift, it’s actually one of the things I find appealing about it.
That’s a false dichotomy. Other languages manage to evolve without losing stability.
You are joking right? Compared to what language? Rust (Swifts main competitor) took 5 YEARs of arguing to even get to 1.0. And that isn’t ABI stable by any means.
Almost everything else is a priority compared to ABI stability, where the main risk is bundling 5meg of runtime with every application. Big deal. Get everything right, then go for ABI stability
swift is DOA. zero stability, overzealous type safety, accepting dumbest ideas in history (++ removal), dreadfully slow build speeds. sticking with obj-c is smartest decision ive ever made.
Amen.
They punted some features so “Swift is dead”? Everyone is blowing this out of proportion. I’m looking forward to the changes they are making, and I’m relieved there will be more time for the team to fix the rough edges that still exist.
They punted some *important* features. Swift will obviously not die, but it could be the difference between it being a niche language for Apple devices and a popular general purpose language.
A few weeks ago I read a story on Ars Technica that claimed Google were contemplating switching to Swift for Android application development (from Java). If that happened it would be awesome, but put yourself in the place of a Google exec weighing up the pros and cons of the move. Which side of the line would “no stable ABI” come under?
The points you make, Jeremy, are pretty reasonable. I was specifically addressing “Swift is DOA” and “sticking with obj-c is smartest decision ive ever made.”
@Charlesism I agree. Every specific criticism of Kevin’s is either wrong or exaggerated to the point of caricature. What concerns me is his overall attitude. He has dismissed Swift because of its perceived failings. Missing all those goals for Swift 3 is going to bring a lot more opinions like this out.
[…] Erica Sadun quotes Chris Lattner: […]
While we’re at it, can we get ++ back? Just kidding. No, not really.
Here you go:
prefix func ++(inout x: Int) -> Int { x += 1 ; return x }
postfix func ++(inout x: Int) -> Int { defer { x += 1 } ; return x }
I leave it to you to generalise it to other arithmetic types.