[Karunamon]

Are there any plans in place for locking down the syntax? Major release 3 is coming and developers are still being expected to hit a moving target.

One of the nice things about C is that K&R era C is just as valid as C written nowadays, but Swift appears to be going in the opposite direction, every major release adding and removing bits of syntax.

As someone unfamiliar with the language, it makes me not want to pick it up, since guides and documentation I read now will be incompatible with the newer release when it happens. Some early toying around during Swift's original announcement led to hard-to-debug errors (in part, caused by terribly useless error messages) when trying identical code on newer releases.

[mikeash]

C got started in 1972, and K&R C dates from 1978 and includes compatibility-breaking changes.

You want a young language to change a lot, because you don't really know what it needs until you get it out there and people use it. You want to make necessary changes as early as possible to cause the least pain. Major changes at the two-year mark will be a lot easier than major changes at the five or ten year mark, and waiting too long to fix a bad decision will probably mean it sticks around forever.

I would expect Swift 3 to be the last release with major source-breaking changes.

[teacup50]

However:

- Almost nobody actually used C prior to 1978.

- Most C compilers have supported both current and previous versions of the C standard via -std flags.

- Other languages with breaking changes, like Java, are similar. Java has always supported specifying the source language level via -src.

Swift is unique in breaking old code completely, without recourse other than semi-functional code rewriting tools.

[mikeash]

Almost nobody actually used Swift prior to mid-2014. Did any 1978 C compilers offer both K&R and prior as options?

IMO the example of Java is a great illustration of why Swift shouldn't be tied to source compatibility too soon. You don't want to be stuck supporting your 1.0 syntax until the end of time, or you'll end up like Java!

[teacup50]

Used everywhere, with decades old libraries that still function fine?

[jamamp]

I believe Swift 3.0 is the last breaking release. Version after this will avoid breaking the API and language as much as possible, and I imagine allow backwards compatibility for changes they do make.

I'm okay with the fast-moving nature of Swift. It's a very young language that obviously needed a lot of changes, and if they had to take the time to make the earliest features available all the way in version 3, Swift would already be bloated. But they have been able to do away with backwards compatibility which is difficult in the industry, and I think it allowed them to make a richer language, not held back by anything.

Side note: For at least some of the changes they've made, they've also built into the compiler and Xcode smart error messages that see the old syntax, and allow you to click one button to fix it to the latest syntax. Such as the old `for i in 0..10 {}` to the new `for i in 0..<10 {}`, Xcode will tell you to basically insert the `<` for the new operator.

[wlesieutre]

Certainly a problem they're aware of, and they're trying to get as many breaking changes done in 3.0 as possible. There may or may not be more in 4.0, but they will definitely be smaller.

> 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.

http://ericasadun.com/2016/02/29/getting-ready-for-swift-to-...

[drakenot]

Swift is still really young. Now is the time for these breaking changes. As someone who has been working with Swift since its public release, I haven't found the "moving target" to be that disruptive to my development. Even the cases that the migrator fails to handle have taken me less than an hour or so to fix myself on a fairly large Swift app.