Breaking changes in Swift 6

Evolution Discussion
62

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

2 Likes
63

Only very optimistically; I donā€™t think ā€œno more security fixes for Swift 5ā€ would be very practicable for Apple. :crazy_face:

64

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
Upon Swift 6: Solve inconsistency within the language
65

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.

2 Likes
66

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
67

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.

68

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.

69

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.