Breaking changes in Swift 6

Honest question: Does this mean Swift 6 will never arrive? Are we going to be on Swift 5.x forever?

1 Like

No, that's not what that means; it's just that changes which cause a significant burden need to be carefully balanced, at the very least so that they can be adopted incrementally.

2 Likes

So: Breaking changes that are easy to fix, or even could be nearly 100 migrated by the IDE are still possible, and that’s how we get to the next major release?

It's something we're going to have to judge case-by-case, but the threshold for what the benefit of the change has to be is very high.

Can these types of things be corrected by adding the new form and eternally deprecating the existing API so it’s technically a nonbreaking change?

5 Likes

I'm with the camp of people saying to limit the number of breaking changes: Swift was near-impossible to learn (and teach) because half the articles on the web were for what is effectively a different language, and people are rarely circumspect enough to mention their Swift version.

Having a stable target and trying to restrict source-breaking changes to removing actively dangerous ("harmful") aspects (i.e. code beginners shouldn't write anyway) and making the language more consistent would ensure the language stays welcoming to beginners.

4 Likes

+9999 from me too

5 Likes

Most importantly though, this :point_up_2::point_up_2::point_up_2:

Apple consistently thumbs its nose at backward compatibility in favor of innovation (i.e., removal of headphone jack et al.), and every time they make one of those decisions I find that amid and despite the myriad moans from Crustys the world-over (cultural reference here), I'm in support of the decision because I'm in support of the ethos.

To avoid making a positive breaking change to Swift because developers are busy and don't have time for the maintenance is like skipping the gym because you're working late. Is it sometimes the right call? Absolutely. There are non-negotiable deadlines and only so many hours in a day, so the gym will get skipped sometimes, or even often, depending on one's current life chapter. But would skipping the gym and working late be good as a permanent life policy? Nobody would deny that we would get more work done, but... at what cost? The little nicks, scrapes, curvatures and discolorations build up over time, and with no regular exercise to wash them away they calcify. Once you're living in an atrophied, warped and ultimately mangled body, the fruits of all that youthful, late-night labor are much harder to appreciate, which should affect the upfront calculation of whether it's worth it.

I know that right now Swift is an entrepreneurially-minded youth trying to make its way in the world, and to that end it needs to skip the gym sometimes, spend some late nights, and cater to the clientele. Let's not lose sight, however, of that the only reason that that matters is that we plan to arrive at our envisioned future in which Swift is a dominant and ubiquitous language that we and the rest of the world get to use for everything. The only reason I desire that future is because of how much I enjoy the programmatic world inside of Swift. It is elegant, powerful, ergonomic, customizable - it invites and inspires the nimble developer. While we are coding, swimming in the world of Swift for work or play, our quality of life is being directly affected. Many people can't imagine why someone would subject themselves to the apparent tedium of being a programmer, but I always respond that they've likely had a false introduction to programming and that I'd be happy to let them in on my very non-tedious inner world with Swift. The minimalist beauty of Swift is the only reason that I'm willing to spend so much of my time in there, and it is the only reason, therefore, that I even want Swift to succeed, because if it were to lose its beauty in the process of taking over the world then I would end up leaving it for another language, or for another passion and profession altogether if there's no other language.

Therefore, I hope that we can find a compromise in our culture and policy whereby breaking changes can be throttled, factored, delayed, etc. to our hearts' content (or rather, to our clientele's hearts' content), but that our guiding philosophy is that breaking changes are ultimately needed, they are healthy, and they are welcomed as members of our future if not our present.

9 Likes

In my opinion significant breaking changes should be adopted incrementally deprecating legacy. My experience is bounded with iOS development, and what I can say is:

  1. Rewriting code from ObjC to Swift is very much harder than migrating between Swift versions.
  2. Migration from Swift 2 to Swift 3 was a nightmare in comparison with migration form Swift 3 to Swift 4.2

So, changes that can cause a significant burden should be adopted without much pain for developers.
On the other side, sometimes breaking changes are needed for language "healthy" evolution.

Today we have Java 13, but at the same time, there are many projects, written in Java 5. And there are still many projects, written in pure Objective-C. We can't force people to use new language versions.

Earlier, when Swift was not ABI stable, Swift standard library was embedded in the application binary.
In theory, we can do something like this, but for legacy Swift versions.

What about the idea of embedding legacy Swift versions to the app binary, if the language version of the project is not compatible with the system version?

3 Likes

We can accept python2 and python3 with major changes. If it is a revolutionary change, it should be acceptable.

I don't think stances like must accept breaking change or must not break codes are particularly useful and they should be more of a case-by-case basis.

2 Likes

Migrating the industry from Python 2 to Python 3 took eleven years. It’s probably not a precedent we want Swift to follow if it can be avoided.

15 Likes

So you're saying it's possible? :rofl:

2 Likes

Only very optimistically; I don’t think “no more security fixes for Swift 5” would be very practicable for Apple. :crazy_face:

I would definitely support a revisit of SE-0132 in addition to several other API rename suggestions.

It was already being possibly considered in response to SE-0279

3 Likes

Huge +1 on that. The naming of operations on Collection types is still confusing in some way, and it would be a huge improvement if we can clarify and unify it by Swift 6. I believe most developers will warmly welcome that as long as we can provide a migration assistant, since it’s really a fundamental change.

3 Likes

I think the Sequence/Collection protocols really do need a lot of work. Lots of operations are missing, some have vague, non-descriptive names, and probably quite a lot of them won’t work when we have move-only types.

Also, RangeReplaceableCollection’s replaceSubrange method has to return the indexes of the replaced content, otherwise you can’t really compose any useful algorithms on top of it. The only way to make that change is to make it part of a new, fixed version of RRC.

4 Likes

I know that in many cases bumping an "old" thread is frowned upon - however, in this case my thinking is that this thread should be considered "old" after Swift 6 is released, because in the meantime having a single thread with all of these ideas collected could be better than arbitrarily fracturing it in to many threads... if you think otherwise feel free to let me know and I'm sorry to bother.

Anyway, what I want to add to the list of ideas for breaking changes in Swift 6 is something fairly minor that I hadn't ever paid any attention to until a couple days ago when I thought about it, investigated it, posted about it, and got some interesting information that led me to believe that it would(might) be a good idea to make this change.

The change is this:

Currently, the initial value that is assigned to a static variable is lazily evaluated upon the property being accessed for the first time, even if that first access is merely the act of assigning a new value.

I'm proposing that we could consider changing the final part, such that the whole thing reads "the initial value that is assigned to a static variable is lazily evaluated upon the property being accessed for the first time, except that if the first access is to set a value then the initial value is only evaluated if the property has a didSet that explicitly references oldValue."

See the post for slightly more detail.

I would agree with minimising changes. The one thing I would add is that we often think of major releases as adding major functionality, but in reality we can add major functionality any time we like (concurrency anyone?). Perversely, the only thing people expect is that a motor release breaks due to removing function.

I'd suggest splitting any Swift 6 feature into additions and deletions; put the additions into 5.x and execute the deletions in 6.0.

I think the old thread rule is mostly to stop people from generating email spam from threads that predate the forums. Having said that, when someone else has already made a new thread on the topic, it might be best to link the old thread from the new thread.

I certainly agree with making sure that all the previous discussion is easily accessible from whichever thread we do decide to use. Search, in general, peaked in 1999 and has been progressively worse since. So anything that reduces the need to search for info is a good thing.