When you talk about code breaking, it can mean one of two things.

1. The language semantics change. You need to refactor the way you perform key tasks. This happened when Swift moved away from (..., &NSError) -> Result? patterns to using thrown errors.
2. The language syntax changes. You apply a migrator and boom, everything more or less gets fixed (minus some epsilon of incorrect tweaks).

The latter is an inconvenience. The former is disruptive. If I’m reading the tea leaves correctly, Swift 3 aims to be the last source-breaking change for a while. Swift 4 should be adding more new features instead of redesigning existing ones.

Chris Lattner writes,

Agreed – source breaking changes in Swift 3 are already a given, so we’re going to provide a really great migrator to help move people forward.  Beyond Swift 3, the Swift community will be a much more diverse place with multiple platforms supported and more diverse tools/ide’s used.

As such, source breaking changes will be much more difficult to justify after Swift 3 is out the door, we’re prefer to roll them into Swift 3 where ever possible.

further:

While Swift 4 will probably break *some* code, we really want to reduce cases that happens.

In terms of time frames,

This is why we need to stay focused on making Swift 3 great within the schedule constraints we have, even if it means pushing off a lot of interesting work…

…

I don’t think there is any point in discussing features beyond Swift 3 now, and I think it would be harmful to do so. There isn’t enough bandwidth from the core team to participate in these discussions, and we’d like to keep the rest of the community and contributors focused on what is important to make Swift 3 great.

What happens in Swift 3 will inform what happens in Swift 4. While there are some things that we can predict (e.g. concurrency being a feature) there are many completely different design directions that may prove out to be the best. It is extremely unlikely that a discussion right now would shed any light on the tradeoffs involved that would select the best approach, but it is very likely that a lot of discussion time would be wasted.

I know it requires patience and restraint, but it really is best for everyone involved to wait until the right time to have these discussions. This Fall (for the northern hemisphere) is not that far away and there is a ton of important work to do now.

Getting Swift 3 design goals solidified and into a timetable has been a challenge, especially since the language has been open sourced.

Predicting what will end up in Swift 3 (e.g., “will we achieve our goals?”) is inherently fraught with peril and cannot be done perfectly.  There are a ton of unknowns in design and implementation of any feature (e.g., how do you know how long it will take to implement behaviors when we don’t have a concrete design?), and new work gets added all of the time as we find new problems to solve and the community identifies new problems.  It is also impossible to predict what open source contributors will provide.

Part of the reason we have to say “no” to good ideas is that we are incredibly design and implementation bound.  We have high goals for Swift 3 as it is, but we aren’t 100% certain we’ll be able to achieve them (that’s why they are “goals”, not “certainty”).  I think that we’ve had a consistent approach with Swift 3, where we’re focused on fixing core deficiencies in the base language, fixing implementation issues and designing resilience features that affect ABI stability, while taking on small scope extensions to the language.  This has come at a cost of having to defer discussion on “large” extensions to the language that do not affect the core model (e.g. the memberwise init revamp) but I’m hoping that we will still get some of those for Swift 3.

Overall, this comes back to a higher order philosophy about what Swift 3 is really about: it is about driving the next wave of adoption of Swift by even more people. This will hopefully come from new audiences coming on-board as Corelibs + Swift on Linux (and other platforms) become real, SwiftPM being great and growing into its own, and the Swift language/stdlib maturing even more.

What does this mean looking forward?  Well, Swift 2 to Swift 3 is going to be an unavoidably disruptive change for code since Cocoa renamification is going to land, and we’re going to be building impressive migration technology again.  As such, we should try to get the “rearrange all the deckchairs” changes into Swift 3 if possible, to make Swift 3 to 4 as smooth as possible.  While our community has generally been very kind and understanding about Swift evolving under their feet, we cannot keep doing this for long.  While I don’t think we’ll want to guarantee 100% source compatibility from Swift 3 to Swift 4, I’m hopefully that it will be much simpler than the upgrade to Swift 2 was or Swift 3 will be.

As a final note, watch out for that Cocoa renamification. It’s going to be a doozy.