# Which (breaking) changes would you be willing to accept in a major language release? \[+ Feature wishes\] **URL:** \ **Category:** Discussion\ **Created:** [August 3, 2022, 8:39am UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429 "2022-08-03T08:39:23Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\ **Post date:** [August 3, 2022, 8:39am UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/1 "2022-08-03T08:39:23Z")
Hey dear Swift community. I'd like to spawn a possibly interesting discussion, or rather a shared collection of opinions. I understand that this thread might re-hash some topics, but I find it still very much interesting if we could accumulate the data into a single spot, at least from the active members. In this thread I would like to collect opinions on which breaking changes you would be willing to accept with a major language version release such as Swift 6. > 👀 This thread is NOT about missing features such as variadic generics, generic protocols or anything else, just about the current set of features that you as a Swift developer would like to see to shift / change / receive a breaking change to make your usage of the language more enjoyable. > ⚠ I welcome everyone to this thread to share their opinions, but keep in mind that the intention of this thread is to share your (possibly unpopular) opinion in a civil and productive manner and not to disrespect the opinions of other or worse turn this thread into another toxic place. > 👍 Overlapping opinions are very much welcome. They don't signal that you might have skipped some messages, but rather showcase that there is similar interests in some specific changes. ---
**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\ **Post date:** [August 3, 2022, 8:39am UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/2 "2022-08-03T08:39:39Z")
So here are my personal parts of the language I'd happily accept breaking changes in: - [`where` clauses (in extensions) in regards to type inference.](https://forums.swift.org/t/what-kind-of-magic-behavior-is-this/22014) There are type inference rules in the language which makes the `where` clause partly unintuitive to use as it yields somewhat unexpected results. - [The release / removal of of the `.Type` and `.Protocol`.](https://forums.swift.org/t/improving-the-ui-of-generics/22814/92) A nested `Kind` type does not always fit. A general rebranding of metatypes (possibly with a `meta` keyword, like `any` and `some`) would be very welcome. - [Label rules alignment](https://forums.swift.org/t/pitch-align-label-behavior-for-subscripts/4061) across the entire language including subscripts and operator functions. - [A shift from `public protocol` to `open protocol`](https://forums.swift.org/t/pitch-consistent-public-access-modifiers/5129), where `open protocol` would mean that the user of a framework can conform their types to that protocol, while he/she can only use or view a `public protocol`, but not conform any types to it. This is also known as "closed protocol". - [A rebrand of `private` into `private(file)` and `fileprivate` into `internal(file)` where `(file)` would be a limiter just like `(set)`, while introducing the new `private` which would be type-private by default.](https://forums.swift.org/t/introduce-type-private-access-level/58438/55) - (possibly) A breaking [change to key-paths](https://forums.swift.org/t/throwable-accessors/20509/49) where the types would also be able to store data for effects such as error types or possibly even the async-ness (if that's even a term). ---
**Author:** ![Morten\_Bek\_Ditlevsen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/morten_bek_ditlevsen/32/28133_2.png) [@Morten\_Bek\_Ditlevsen](https://forums.swift.org/u/Morten_Bek_Ditlevsen)\ **Post date:** [August 3, 2022, 8:47am UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/3 "2022-08-03T08:47:27Z")
If one considered ABI breaking changes too, it would be interesting to consider how the standard library types might be implemented in today’s swift. Like using opaque result types for different collection types in order to hide the implementation details that are ‘leaking out’ today. ---
**Author:** ![masters3d](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@masters3d](https://forums.swift.org/u/masters3d)\ **Post date:** [August 3, 2022, 1:54pm UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/4 "2022-08-03T13:54:29Z")
I think this is a good idea but instead of collecting a wish list from the community, it might be best to ask the language group of what is currently on the docket for swift 6 for breaking change. ---
**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\ **Post date:** [August 3, 2022, 2:11pm UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/5 "2022-08-03T14:11:55Z")
I'm not against this, but this should also not limit us sharing ideas for theoretical breaking changes regardless if they make it into Swift 6, Swift 7 or ever. 🙂 ---
**Author:** ![technogen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/technogen/32/45489_2.png) [@technogen](https://forums.swift.org/u/technogen)\ **Post date:** [August 3, 2022, 4:20pm UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/6 "2022-08-03T16:20:55Z")
Aside from literally everything @DevAndArtist listed in [his wish list](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release/59429/2), I'd like: - Trailing closure syntax to not allow omitting the label. - Import statements to default to `@_implementationOnly`, which would be the same as `internal import`, where current unqualified import statement would be achieved with `public import` and `@_exported import` would be achieved by `open import`. - Remove `Comparable` requirement from `Collection.Index` In favor of `index(_:precedes:)` on the collection itself to enable a reasonable implementation of a linked list to conform to `Collection` (in which case `index(_:precedes:)` would have **O(n)** complexity, instead of the expected **O(1)**). - Remove global-scope `private` In favor of `fileprivate` (or `private(file)`) to avoid inconsistency and confusion. - Change the meaning of an unqualified protocol conformance clause to have `internal` access level (meaning that only code in the same module as the conformance declaration would see the conformance), where current behavior would be achieved with `public` conformance. ---
**Author:** ![Nickolas\_Pohilets](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nickolas_pohilets/32/10659_2.png) [@Nickolas\_Pohilets](https://forums.swift.org/u/Nickolas_Pohilets)\ **Post date:** [August 3, 2022, 4:41pm UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/7 "2022-08-03T16:41:27Z")
I’d be interested to see universal hashability for all types, including function types and using CustomHashable when default behavior needs to be overridden. ---
**Author:** ![abdel-17](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/abdel-17/32/24248_2.png) [@abdel-17](https://forums.swift.org/u/abdel-17)\ **Post date:** [August 3, 2022, 4:54pm UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/8 "2022-08-03T16:54:15Z")
How would you hash function types? ---
**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\ **Post date:** [August 3, 2022, 5:03pm UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/9 "2022-08-03T17:03:03Z")
I would like to point out once more. I'd like this thread to focus on breaking changes or changes that has to be made in order to unlock something else in the future, rather than general missing features. Thanks everyone. 🙂 ---
**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\ **Post date:** [August 3, 2022, 5:04pm UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/10 "2022-08-03T17:04:40Z")
> [@technogen](#): > > In favor of `fileprivate` (or `private(file)`) If you meant to use the notation which I used then it'd be `internal(file)`. ;) ---
**Author:** ![technogen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/technogen/32/45489_2.png) [@technogen](https://forums.swift.org/u/technogen)\ **Post date:** [August 3, 2022, 5:05pm UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/11 "2022-08-03T17:05:39Z")
> [@DevAndArtist](#): > > If you meant to use the notation which I used then it'd be `internal(file)`. ;) Yes, that's right. 😊 ---
**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\ **Post date:** [August 3, 2022, 5:10pm UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/12 "2022-08-03T17:10:33Z")
> [@abdel-17](#): > > How would you hash function types? A bit off-topic, but hashing types is already possible by [converting their metatype into an `ObjectIdentifier`](https://developer.apple.com/documentation/swift/objectidentifier/init(_:)-86u7l) and getting the hash value from it. The more interesting part might be hashing a reference to a function / closure. ---
**Author:** ![technogen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/technogen/32/45489_2.png) [@technogen](https://forums.swift.org/u/technogen)\ **Post date:** [August 3, 2022, 5:21pm UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/13 "2022-08-03T17:21:45Z")
> [@DevAndArtist](#): > > The more interesting part might be hashing a reference to a function / closure. I imagine something like this: ```swift func hash(into hasher: inout Hasher) { hasher.combine(implementationPointer) for capture in captureGroup { hasher.combine(capture) } } ``` ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [August 3, 2022, 8:24pm UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/14 "2022-08-03T20:24:58Z")
one source-breaking change i would really like to see, is to be able to use the collection type sugar to refer to nested types: ```swift // currently: let index:Dictionary.Index // ideal: let index:[Key: Value].Index ``` ---
**Author:** ![abdel-17](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/abdel-17/32/24248_2.png) [@abdel-17](https://forums.swift.org/u/abdel-17)\ **Post date:** [August 3, 2022, 8:42pm UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/15 "2022-08-03T20:42:35Z")
How is this source-breaking? Isn’t it a purely additive change? ---
**Author:** ![Nickolas\_Pohilets](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nickolas_pohilets/32/10659_2.png) [@Nickolas\_Pohilets](https://forums.swift.org/u/Nickolas_Pohilets)\ **Post date:** [August 3, 2022, 9:04pm UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/16 "2022-08-03T21:04:37Z")
You can treat every closure as a struct that carries unique identifier of the literal and all the captured variables. So you just need to compare/hash those. From the first sight it may seem that you can use function pointer as unique identifier of the literal, but reabstraction thunks make things more complicated. You’d need to follow a chain of thunks until you find the original closure that can be used for comparison. But even that might be not enough because of inlining. Then you’d need to compare metadata of the context objects as a stable identifier. This may block some compiler optimizations and have other costs that need to be carefully evaluated, but overall is definitely possible. ---
**Author:** ![tera](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tera/32/38201_2.png) [@tera](https://forums.swift.org/u/tera)\ **Post date:** [August 3, 2022, 9:51pm UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/17 "2022-08-03T21:51:07Z")
This won't happen (force of habit, etc), but if I were to dream, here's a list of breaking changes: - make Int a typealias to Int32/64 (and seriously consider having it mapped to Int32 even on 64 bit devices) - make `Float` a typealias to `Float32/64` and remove `Double` - make `CGFloat` a typealias to `Float` and remove all the hackery about `CGFloat <-> Float` interop. - alternatively (even better) make CGFloat a typealias to a new Fixed datatype. - remove NaN's (or expose the relevant functionality by some explicit additional APIs, so for every floating value "value == value" is true without exceptions). - change `Optional.none` to `Optional.nil` and remove bare `nil` - expose `Bool` as an enum with `.false` and `.true` and remove bare `false` / `true` - make enum values mutable (not entirely source breaking, can be made additive) - alternatively make struct values immutable (although that would be too radical). - change async from: ```swift func foo() async -> Int to: async func foo() -> Int ``` - change discardableResult from: ```swift @discardableResut func foo() -> Int to: func foo() -> discardable Int ``` - make "switch" and "do" statement expressions: ```swift func foo(x: Int) -> Int { switch x { case 1: 100 case 2: 200 } } func bar() { let x = do { 123 } } ``` - change `[:]` to `[]` (use context to treat `[]` as empty dictionary when needed) - make commas optional e.g.: ```swift let items: [String: Int] = [ "first" : 1 "second" : 2 "third" : 3, "fourth" : 4 // comma is needed here "fifth" : 5, // comma still allowed here ] ``` perhaps even here: ```swift foo( expression1 expression2 expression3 ) ``` - allow types inference for parameter names: ```swift func foo(x = true) { ... } ``` - allow types inference for function return type (additive): ```swift func foo() -> _ { 123 } ``` - make closure parameters less ugly: ```swift { $0 * $1 } ---> { p0 * p1 } // or param0, or value0, etc, or this: { p[0] * p[1] } // or this: { p.0 * p.1 } ``` alternatively (even better) derive closure parameter names like so: ```swift func foo(execute: (_ a: Int, _ b: Int) -> Int) { ... } .... foo { a * b } ``` - change autoclosure from: ```swift func foo(x: @autoclosure () -> Bool) -> Bool { x() // parens } to func foo(x: lazy Bool) -> Bool { x // no parens } ``` - change `&&` to `&` and `||` to `|` (they will still "short-circuit" for Bool ops) - change Bool's not `!` to something else like suffix `.not` and change `!=` to `<>`. Use pling only to denote "optional unwrapping" business (something that can terminate the app). - while on this: check all current places that can terminate the app and introduce either a pling or a try in there, examples: ```swift func foo() { let a = Dictionary(uniqueKeysWithValues: [(1, 1), (1, 1)]) // prohibit let a = Dictionary(uniqueKeysWithValues: [(1, 1), (1, 1)])! // either this let a = try! Dictionary(uniqueKeysWithValues: [(1, 1), (1, 1)]) // or this let b: [Int: Int] = [1:1, 1:1] // prohibit let b = [Int: Int]([1:1, 1:1])! // either this let b = try! [Int: Int]([1:1, 1:1]) // or this let c: Set = [1, 1] // prohibit let c = Set([1, 1])! // either this let c = try! Set([1, 1]) // or this let array: [Int] = [1, 2, 3] let d: Int = array[123] // prohibit let d: Int = array[123]! } ``` - change `->` to `:` - make subscript label rules compatible to function label rules ```swift subscript(_ internalName: Int) --> allow only: foo[1] subscript(name: Int) --> allow only: foo[name: 1] subscript(externalName x: Int) --> allow only: foo[externalName: 1] ``` ---
**Author:** ![pilky](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/pilky/32/7636_2.png) [@pilky](https://forums.swift.org/u/pilky)\ **Post date:** [August 4, 2022, 3:28pm UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/18 "2022-08-04T15:28:04Z")
One big one that I’d love to see (but will probably never happen as it’s would change pretty much all Swift code): completely change the syntax for protocol conformance. I would heavily argue that Objective-C did it far better where concrete types and protocols were separate (e.g. whereas in Swift you’d do `class Foo: Superclass, Protocol1, Protocol2 {}`, in Obj-C you’d have `@interface Foo : Superclass `). This improves readability and also gets around several issues where a protocol and a concrete type can have the same name, as they are now used in different contexts so the compiler can easily differentiate ---
**Author:** ![Jean-Daniel](https://avatars.discourse-cdn.com/v4/letter/j/977dab/32.png) [@Jean-Daniel](https://forums.swift.org/u/Jean-Daniel)\ **Post date:** [August 5, 2022, 5:51am UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/19 "2022-08-05T05:51:33Z")
Remove the `Any` and `AnyObject` classes in favour of modern alternatives. ---
**Author:** ![ebg](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ebg/32/23208_2.png) [@ebg](https://forums.swift.org/u/ebg)\ **Post date:** [August 5, 2022, 2:20pm UTC](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429/20 "2022-08-05T14:20:43Z")
- Finally fix the static protocol extension dispatch footgun - Deterministic retroactive conformance resolution - Require protocol conformance marker on implementing methods similar to `override` (disambiguate conformance, clean up old methods) - Replace stringly-typed `callAsFunction` with a proper attribute - Eliminate fileprivate, and go back to the drawing board on access control - Internal imports by default - Undo some of the SwiftUI purpose-built "magic": omit return, multiple trailing closures, result builders - Pure functions by default - Disambiguate protocol conformance and inheritance [Next page](https://forums.swift.org/t/which-breaking-changes-would-you-be-willing-to-accept-in-a-major-language-release-feature-wishes/59429.md?page=2)