Breaking changes in Swift 6

Evolution Discussion
1

I read these kind of things very frequent in the last couple weeks. That makes me wonder, what kind of breaking changes are considered/allowed in Swift 6? There are a couple other things that come to my mind that would require a breaking change to be really fixed / work.

13 Likes
2

Removing inout-to-pointer conversions would be great. It would break a lot of code, but it’d also probably fix a lot of bugs.

9 Likes
3

Do you mean removing all inout-to-pointer conversions, or would you still like to have them for imported C functions?

4

Some source (or maybe ABI, IDK) breaking changes I would like to see are:

  • rename Strideable.distance(to:) to Strideable.displacement(to:)
    • Because it is intended to return signed values.
  • Fix open vs. public protocols
    • we need sealed protocols, and have a perfectly fine way of making the distinction, if it were not source breaking.
  • add FloatingPoint.(&==) & co.
    • These would be IEEE standard comparisons, while Equatable.(==) would either
      • Trap if lhs.isNan || rhs.isNan, or
      • return true if lhs.isNan && rhs.isNan
  • I would also like to see a non-Comparable version of Strideable, but adding that would be ABI breaking IIRC.
    • It would be describing a Torsor or an abstract Point, I think.
7 Likes
5

YES PLEASE. This is one of the issues I had in mind when creating this thread.

  • From top of my head I'd like to get rid of access control on extensions, basically the proposal I messed up years ago as I failed to communicate my intend correctly and mislead with the proposal title. And removing the indirect convenience on the entire enum (not for individual cases), although I don't remember why I actually wanted this.

  • Add a third generic type parameter to KeyPath family to support errors, which would allow throwing accessors more naturally.

  • One wish (not sure if it EVER happens) is the alignment of labeling rules for all the things including operators and subscripts. Subscript label rules are very much annoying.

7 Likes
6

We still need some mechanism to perform such conversions. Today they're implicitly performed in function call argument position. Do you imagine that we could make them explicit? Or is there some other language feature you had in mind that could potentially replace them?

1 Like
7

I don't claim to speak for the core team, but my personal opinion is that we should consider a potential small number of changes to fix quirks in the language that are actively harmful in practice, or make the language harder to learn. Examples would be cleaning up some of the implicit conversions in the type checker, or narrowing down associated type inference to make it easier to reason about and implement correctly.

I'd be nervous about opening up the release to a broader "rethinking" of anything, especially things that have in the past been controversial (access control, etc).

19 Likes
8

That just bit me... I thought it would always return a positive value.

4 Likes
9

If I had to pick the only access control related issue, it would be the open vs. public protocol thing. I stopped using private and fileprivate completely in my code and I'm happy with that.

5 Likes
10

Don't forget generics… afair there has been some support for adding default types, and imho there's no good reason to treat those parameters differently.

11

What is it about generics and labeling that is different? :thinking:

12

I don't think implementing default types for generic parameters requires any source (or ABI) breaking changes. It's just syntactic sugar for spelling out the defaults explicitly where omitted.

7 Likes
13

let result = Result<Success: Int, Failure: NSError>.success(42)
-> computer says "Consecutive statements on a line must be separated by ';'"

I hope so :-) - but imho usability would would not be that great without labels.
Many generic types only have a single parameter with a more or less obvious meaning, but in more complex setups, labels become more important [afair we once had a rule that for method call, the first label would be skipped automatically as well].

2 Likes
14

The Core Team has no interest in pursuing changes that would massively invalidate existing code.

10 Likes
15

Are these the changes you want to make?

16

Hello Slava And Core Team,

Do you think Swift 6 is when possibly argument labels may come back to closures:

https://forums.swift.org/t/argument-labels-in-callbacks/5287

Every time I rewatch the original Swift API Design guidelines talk about the beauty of argument labels to make code clearer at call site I think about that old proposal (e-mail thread linked in that post) and I would really like to know if there is a chance for this to be addressed. Not everyone can help making this change in the compiler and language, but many would benefit... and I am conscious that potentially source breaking changes are less and less acceptable as time goes on.

14 Likes
17

Along those lines, yeah.

18

It’d be a (trivially fixable) source-breaking change if we did the same thing with generic parameter labels as we do with function parameters. Namely, externally unlabeled arguments are preceded by a _. Like, struct Array<_ Element> {...}

If we don’t want the labeling rules to be same across the whole language, then yeah, I can’t think of a reason there’d be any issues with source-compatibility.

19

They already aren't the same across the whole language because of subscripts.

Are there any cases where we would want the external label to be different than the type parameter name itself? If not, it might make sense to allow "labels" to be optionally used at the usage site for clarity and / or disambiguation without ever requiring them to be used. This would be 100% source compatible.

1 Like
20

Oh yeah! Forgot about subscripts.