# Upon Swift 6: Solve inconsistency within the language **URL:** \ **Category:** Discussion\ **Tags:** swift-evolution\ **Created:** [September 29, 2021, 8:05am UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437 "2021-09-29T08:05:06Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![stevapple](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/stevapple/32/31979_2.png) [@stevapple](https://forums.swift.org/u/stevapple)\ **Post date:** [September 29, 2021, 8:05am UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437/1 "2021-09-29T08:05:06Z")
The arrival of Swift 6 means a chance for “regretting” some language designs with API breakage — after 3 years which is fairly a long time for Swift and the Swift community. With the Swift 3.2 and Swift 4.2 effort, transition to a breaking Swift release has proved to be a lot smoother. I would suggest we pick up some of the deferred breaking pitches, which intended to eliminate inconsistency within the language. These ideas have already received positive feedbacks from the community, and yet didn’t make their ways into reality. ## Naming Inconsistency: Revisit SE-0132 [SE-0132](https://github.com/apple/swift-evolution/blob/main/proposals/0132-sequence-end-ops.md) proposed to rename and redesign the existing `Sequence` snd `Collection` APIs by rationalizing them according to the [API Design Guidelines](https://swift.org/documentation/api-design-guidelines/). The Core Team did regard these changes as [“too expensive”](https://github.com/apple/swift-evolution/pull/898), but I believe not fixing them as soon as possible would become the really expensive thing. Such confusing naming from the standard library is a significant problem which will impact all the future users. Given ABI stability goal added in Swift 5, we’re already suffering more to fix it. I would suggest how we deal with SwiftPM 4 manifests: add a `libStdlib5` fallback in future releases for compatibility issue, until we finally decide to drop it (through future evolution). I’m not an expert in ABI though, if there’s any problem welcome to point out. Links: - [Original proposal](https://github.com/apple/swift-evolution/blob/main/proposals/0132-sequence-end-ops.md) - [Original review thread](https://forums.swift.org/t/short-review-se-0132-rationalizing-sequence-end-operation-names/3533) - [Revisiting attempt upon Swift 4](https://forums.swift.org/t/revisiting-se-0132-rationalizing-sequence-end-operation-names/6934) - [Expectation from Swift 5 user](https://forums.swift.org/t/bad-naming-in-standard-library/25058) - [Latest call from the Swift 6 thread](https://forums.swift.org/t/breaking-changes-in-swift-6/35928/64) ## Design Inconsistency: `throws` overload `throw`ing/non-`throw`ing overload is the new inconsistency introduced by the [amendment to SE-0296](https://forums.swift.org/t/amendment-se-0296-allow-overloads-that-differ-only-in-async/49808). As [Chris pointed out](https://forums.swift.org/t/amendment-se-0296-allow-overloads-that-differ-only-in-async/49808/31): > [@\[Amendment\] SE-0296: Allow overloads that differ only in async](https://forums.swift.org/t/amendment-se-0296-allow-overloads-that-differ-only-in-async/49808/31): > > I believe that it is important to allow async overloading, but even more important to keep the language consistent about how it handles effects. Inconsistency makes the language more complex and makes future things more difficult to add. There are, of course, considerations regarding source breakage on introducing this in Swift 5. For a healthier language design, there’s no better opportunity to add (and enforce) this in Swift 6. The [Core Team decision](https://forums.swift.org/t/accepted-amendment-to-se-0296-allow-overloads-that-differ-only-in-async/50117) addressed: > [@\[Accepted\] Amendment to SE-0296: Allow overloads that differ only in async](https://forums.swift.org/t/accepted-amendment-to-se-0296-allow-overloads-that-differ-only-in-async/50117/1): > > The Core Team is amenable to considering a proposal for overloading on `throws` , separately from this amendment. Part of the motivation for such a proposal can be consistency with `async` . Links: - [Chris Lattner’s comment on SE-0296 amendment](https://forums.swift.org/t/amendment-se-0296-allow-overloads-that-differ-only-in-async/49808/31) - [SE-0296 amendment acceptance note](https://forums.swift.org/t/accepted-amendment-to-se-0296-allow-overloads-that-differ-only-in-async/50117) - [Another attempt to overload `throws`: Optional Throws](https://forums.swift.org/t/pitching-optional-throws-in-swift/51650) ## Behavioral Inconsistency: Eliminate implicit initializations Last week, Jordan Rose (@jrose) [pitched to remove the implicit initialization of Optional variables](https://forums.swift.org/t/pre-pitch-remove-the-implicit-initialization-of-optional-variables/52300) and received heated discussion, including suggestions on extending the pitch to include `PropertyWrapper`. Behavioral inconsistency like implicit initializations is more subtle, yet has potential to cause bigger problems because they burden users with kinds of “differences”. As Jordan [explained himself](https://forums.swift.org/t/pre-pitch-remove-the-implicit-initialization-of-optional-variables/52300/21): > [@Pre-pitch: remove the implicit initialization of Optional variables](https://forums.swift.org/t/pre-pitch-remove-the-implicit-initialization-of-optional-variables/52300/21): > > Consistency is good because it means fewer things to remember, and that code is less likely to break when one piece is swapped out for another. In fact, this piece of change has already been pitched four times since 2017. It’s time to get it fixed now. Links: - [First pitch in Nov '17](https://forums.swift.org/t/pitch-remove-default-initialization-of-optional-bindings/6961) - [Second pitch in Jan '19](https://forums.swift.org/t/remove-implicit-initialization-of-optionals/19482) - [Third pitch in Jun '19](https://forums.swift.org/t/prepitch-optional-variables-should-require-explicit-initialization/26077) - [Fourth pitch in Sep '21](https://forums.swift.org/t/pre-pitch-remove-the-implicit-initialization-of-optional-variables/52300) ## Others I believe there are more inconsistent cases which l’m not able to cover, so welcome to address them **in other threads** (let’s keep this thread focused). I would like to call for the whole community to push these efforts and make consistency a real goal for Swift 6. ---
**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:** [September 29, 2021, 2:20pm UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437/2 "2021-09-29T14:20:29Z")
If I had one wish it would be to "fix" protocols in Swift to make them safer to use, by finally fixing: 1. [Dynamically dispatch protocol extension members](https://forums.swift.org/t/dynamically-dispatched-protocol-extension-members/32566) 2. [Role Keywords to Protocol Implementations to Reduce Code Errors](https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4) There are other Swift regrets that could be taken back now too like eliminating `fileprivate`. ---
**Author:** ![Nobody1707](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nobody1707/32/2169_2.png) [@Nobody1707](https://forums.swift.org/u/Nobody1707)\ **Post date:** [September 29, 2021, 6:34pm UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437/3 "2021-09-29T18:34:10Z")
Returning to Swift 2 access control is the dream, but I'm not sure it'll get enough traction. I'd also like to suggest that, regardless of what else is done in Swift 6, we fix [SR-103](https://bugs.swift.org/browse/SR-103). Default implementations of protocol requirements on a base class absolutely should be part of that class's vtable. ---
**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\ **Post date:** [October 7, 2021, 12:28am UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437/4 "2021-10-07T00:28:22Z")
> [@stevapple](#): > > The arrival of Swift 6 means a chance for “regretting” some language designs with API breakage — after 3 years which is fairly a long time for Swift and the Swift community. With the Swift 3.2 and Swift 4.2 effort, transition to a breaking Swift release has proved to be a lot smoother. > > I would suggest we pick up some of the deferred breaking pitches, which intended to eliminate inconsistency within the language. These ideas have already received positive feedbacks from the community, and yet didn’t make their ways into reality. Swift 6 does afford us with the possibility of making some source-incompatible changes. I want to highlight the place where you quoted me in regards to SE-0296: > Part of the motivation for such a proposal can be consistency with `async` . "Consistency" can be _part_ of an argument to make a source-incompatible change, but it should not be the only argument or even a load-bearing one. Source-incompatible changes have a high bar, because they need to be correcting a serious problem or unlocking some potential that is otherwise unavailable without them. I'll give an example that is inconsistent that we would _not_ accept: making subscript argument labels behave the same way as function argument labels, so you don't have to "double-up" subscript parameter names to get an argument label: ```swift subscript(row row: Int) -> Double { ... } // inconsistent with func get(row: Int) -> Double ``` It would make the language more consistent, but it would also cause a lot of code churn where Swift \< 6 and Swift 6 have the same code meaning two different things. We would not consider this. Additionally, ABI changes are not in scope. Swift 6 needs to interoperate with Swift 5 code on a per-module basis, including making it possible for a Swift 5 module to be updated to Swift 6 without breaking clients, and ABI changes work against that goal. We should consider the ABI a fixed entity that will, effectively, never change. To your specific feature requests: > [@stevapple](#): > > Naming Inconsistency: Revisit SE-0132 This one is significantly source-breaking, and would change our basic terminology for working with sequences and collections. I think we are too far into Swift to make fundamental changes like this, and the "harm" from keeping the current set of names is far less than the cost of introducing source incompatibilities of this scale. > [@stevapple](#): > > Design Inconsistency: `throws` overload As I noted in the thread you quoted, this seems like a reasonable thing to consider. Make sure its justification isn't just "consistency", though. > [@stevapple](#): > > Behavioral Inconsistency: Eliminate implicit initializations This one will be interesting, and it's not really about consistency: it's about a one-off rule to eliminate the `= nil` boilerplate that a number of folks think is problematic. We'd need to understand how much source incompatibility it actually introduces (which, alas, means basically implementing the whole thing), but it seems like it could fit with Swift 6. Doug ---
**Author:** ![mtsrodrigues](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mtsrodrigues/32/34169_2.png) [@mtsrodrigues](https://forums.swift.org/u/mtsrodrigues)\ **Post date:** [October 7, 2021, 2:53am UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437/5 "2021-10-07T02:53:02Z")
> [@Douglas\_Gregor](#): > > This one is significantly source-breaking, and would change our basic terminology for working with sequences and collections. I think we are too far into Swift to make fundamental changes like this, and the "harm" from keeping the current set of names is far less than the cost of introducing source incompatibilities of this scale. I really would like to understand why it's considered so harmful to rename a few methods. I can't wrap my mind around because I imagine that it would be an easy transition. The old methods could be marked as deprecated, IDEs could suggest the change to the new ones and replace all. I have migrated projects from old versions of Swift and Xcode made it very smooth. I'm probably wrong about it but I honestly can't see the problem.These inconsistencies could be solved now and avoid the same discussion in Swift 7, 8 and so on. ---
**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\ **Post date:** [October 7, 2021, 3:51am UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437/6 "2021-10-07T03:51:59Z")
> [@mtsrodrigues](#): > > I really would like to understand why it's considered so harmful to rename a few methods. I can't wrap my mind around because I imagine that it would be an easy transition. The old methods could be marked as deprecated, IDEs could suggest the change to the new ones and replace all. I have migrated projects from old versions of Swift and Xcode made it very smooth. IDEs can help migrate a code base at a time, but they only work for an actively maintained code base. They don’t retroactively fix up answers on StackOverflow, or example code in a tutorial or on a blog. There is a ton of great Swift content out there, and the overall community pays a cost when we go and change things. Years after the Swift 2 -\> 3 transition, you’d still regularly find swift 2 code out there that just doesn’t work. Additionally, I think there is an overall “budget” for the amount of surface-level change we can tolerate in Swift 6. If it’s too different, especially if it’s “just syntax” that isn’t massively better, it will dissuade users from adopting the new language mode. Even a perfect migration is risky if it causes a large amount of churn in the code base. So, with proposals to make source-incompatible changes, I think we truly have a zero-sum game, where changing a few names over here means we might not get a more substantive change over there. Finally, this proposal was rejected before. We audit don’t reconsider rejected proposals unless there’s new information that changes the discussion. I don’t think we have that here, and the reasons for rejection (ie, not creating too much churn) are stronger now than they were then. Doug ---
**Author:** ![1-877-547-7272](https://avatars.discourse-cdn.com/v4/letter/1/278dde/32.png) [@1-877-547-7272](https://forums.swift.org/u/1-877-547-7272)\ **Post date:** [October 7, 2021, 5:07am UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437/7 "2021-10-07T05:07:27Z")
One thing I’d like to see relaxed in Swift 6 is Objective-C bridging. Currently, Swift allows `NSString` methods to be called on `String` instances. However, these functions often have better alternatives that are native to Swift: ```swift let foo = "hello ".appending("world") // use of `+=` or `+` is preferred ``` And many of these `NSString` methods aren’t Unicode-correct (instead operating on UTF-16 code units), which is unexpected behavior to many people as native `String` methods _are_ Unicode-correct. ```swift let bar = "👨‍👩‍👧‍👦".padding(toLength: 14, withPad: "0", startingAt: 0) // 👨‍👩‍👧‍👦000 let baz = "👨‍👩‍👧‍👦".padding(toLength: 10, withPad: "0", startingAt: 0) // 👨‍👩‍👧‍� ``` And these methods return bridged `NSString`s instead of native strings, which can be unexpected since there is no indication that they will return a bridged `NSString`. Despite this inconsistency and [its associated confusion](https://forums.swift.org/t/string-padding-method-is-broken/14417), people still recommend the use of these functions over their Swift equivalents. If you search for [“how to pad a string in swift” in Google](https://www.google.com/search?hl=en&q=how%20to%20pad%20a%20string%20in%20swift), every search result tells you to use `NSString.padding`. (At least, it does for me — Google is known to have a “filter bubble” that changes search results based on the information it collects from you.) In addition, I think that Swift is mature enough now that we should stop relying on C / Objective-C interoperability behavior for simple things like this. We should remove these kinds of “bridged” methods from native Swift types. If a programmer really wants to use these methods, we should require them to cast the Swift type to the Objective-C equivalent like so: ```swift let hello = "hello " let helloWorld = (hello as NSString).appending("world") ``` There should also be a warning in the `NSString` documentation that most of its methods operate on UTF-16 code units and do not have Unicode-correct behavior. * * * I’d also like to see some of the Foundation types be re-renamed back to their Objective-C names. Types like `NumberFormatter` and `Timer` look like Swift types, but act like Objective-C classes in a way that’s inconsistent with the rest of the language. Also, `NumberFormatter` now has a native Swift equivalent and `Timer` has a Combine equivalent. Having two native-looking APIs for the same thing is confusing and should be avoided. The renaming of these types happened a long time ago (relatively), back when Swift was still dependent on Objective-C for doing almost anything. Now, Swift is more independent, with its own APIs and its own style, and Foundation should reflect that. ---
**Author:** ![stevapple](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/stevapple/32/31979_2.png) [@stevapple](https://forums.swift.org/u/stevapple)\ **Post date:** [October 7, 2021, 6:08am UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437/8 "2021-10-07T06:08:54Z")
> [@Douglas\_Gregor](#): > > > [@stevapple](#): > > > > Naming Inconsistency: Revisit SE-0132 > > This one is significantly source-breaking, and would change our basic terminology for working with sequences and collections. I think we are too far into Swift to make fundamental changes like this, and the "harm" from keeping the current set of names is far less than the cost of introducing source incompatibilities of this scale. Let’s say, if this can go into Evolution again, there would be some milder ways to do the transition. For example, it’s okay to keep the old naming as deprecated (warning), until we finally decide to drop them. ABI could keep the same. There’s no definite large-scale source breakage. Furthermore, I think SwiftSyntax and the Swift compiler is now smart enough to do such “renaming” migration for us. For any code that can compile with Swift 5, it should be almost painless. ---
**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\ **Post date:** [October 7, 2021, 6:12am UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437/9 "2021-10-07T06:12:47Z")
> [@stevapple](#): > > Let’s say, if this can go into Evolution again, there would be some milder ways to do the transition. For example, it’s okay to keep the old naming as deprecated (warning), until we finally decide to drop them. ABI could keep the same. There’s no definite large-scale source breakage. > > Furthermore, I think SwiftSyntax and the Swift compiler is now smart enough to do such “renaming” migration for us. For any code that can compile with Swift 5, it should be almost painless. We had support for "renaming" migration since Swift 3. It's not a problem of tools, but of deprecating a bunch of existing, well-documented APIs where the only justification is that we don't like the name. But the name we're proposing is one that's already been rejected by this same process. Look, you're welcome to bring up the proposal again, but if it's a rehash of the old discussion with no new information, I see no way it's going to gain traction. Doug ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [October 7, 2021, 12:14pm UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437/10 "2021-10-07T12:14:10Z")
> [@Douglas\_Gregor](#): > > Look, you're welcome to bring up the proposal again, but if it's a rehash of the old discussion with no new information, I see no way it's going to gain traction. For my part, I certainly would not welcome a rejected proposal being brought up again without new information. It’s disrespectful of all participants’ time and effort. There was a thorough discussion and a full review process, and a decision was reached. All the arguments are there as legible as the day they were written, and anyone is free to relive it themselves without taking up the whole community’s time and effort. ---
**Author:** ![stevapple](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/stevapple/32/31979_2.png) [@stevapple](https://forums.swift.org/u/stevapple)\ **Post date:** [October 7, 2021, 1:14pm UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437/11 "2021-10-07T13:14:17Z")
> [@xwu](#): > > It’s disrespectful of all participants’ time and effort. There was a thorough discussion and a full review process, and a decision was reached. Agree — but SE-0132 is just not the case. Let’s first take a look at the review result: > [@\[Deferred\] SE-0132: Rationalizing Sequence end-operation names](https://forums.swift.org/t/deferred-se-0132-rationalizing-sequence-end-operation-names/3577/1): > > This is a very large proposal very late in the Swift 3 schedule. It has some clearly good pieces to it, but also many parts that are controversial with the community, and requires more design and iteration than time permits. It is best to defer this and make a change when we have something truly great, giving the benefit of proper time to design and evaluate the proposal. > > Thank you to Brent Royal-Gordon and Dave Abrahams for driving this discussion. When the goals and parameters of Swift 4 are established, we should pick up this thread and see what makes sense to do here. This original decision note suggested that this proposal **requires more design and iteration** , and we shall pick it up when the criteria is met. But what happened then? > [@](#): > > The Swift Core Team has discussed this proposal and determined that > the naming changes it proposes for the Standard Library are too extensive > to consider given Swift's source compatibility goals. This piece of decision note has not even been posted on the Swift Forums. Nor did it indicate that any participants outside of the Core Team was involved in rejecting this proposal. This note raises the concept of “too expensive”, while the “deferred work” of this proposal just consists of lowering that cost. * * * The story is: the Core Team deferred it on behalf of the community, and then closed it by themselves. And now, the discussion is going to be suppressed because we’re not able to bring it up if there isn’t any “new information”. What is “new information”? > [@xwu](#): > > All the arguments are there as legible as the day they were written, and anyone is free to relive it themselves without taking up the whole community’s time and effort. We’ve been discussing ways to lower that boundary for transition, to fit it into the ABI goal, to narrow its scale or break it into small pieces. Aren’t there any new information? The discussion around the original proposal and its design is not the vital work for revisiting it now. The original review thread has already pointed a clear and positive direction on the detailed design for us, and we can also adopt new ideas from further discussions. What SE-0132 lacks for today’s review are the **additional** parts we’d like to discuss and brainstorm: ABI stability, source compatibility, transition, and so on. There’re always calls for revisiting SE-0132, because it solves inconsistency and tries to make Swift Standard Library a good example for Swift API design and evolution. Unless we can fit the existing Collection API in a table just as clearly as the one in SE-0132, there will continue to be confusion about the API naming, and SE-0132 preserves its value till then. ---
**Author:** ![George](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/george/32/37757_2.png) [@George](https://forums.swift.org/u/George)\ **Post date:** [October 7, 2021, 5:58pm UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437/12 "2021-10-07T17:58:06Z")
What is your gut feeling about unifying pattern matching and optional unwrapping? Namely, deprecating `if let foo = foo` and requiring it to be `if let foo? = foo`, and thus opening up the possibility of removing the `case` from `case let` so you can do things like `if let .success(foo) = barResult`. ---
**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:** [October 7, 2021, 6:38pm UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437/13 "2021-10-07T18:38:03Z")
> [@George](#): > > `if let .success(foo) = barResult` . We still have to support `case`: ```swift if case .foo(let a, var b) = bar { … } ``` ---
**Author:** ![1-877-547-7272](https://avatars.discourse-cdn.com/v4/letter/1/278dde/32.png) [@1-877-547-7272](https://forums.swift.org/u/1-877-547-7272)\ **Post date:** [October 7, 2021, 8:59pm UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437/14 "2021-10-07T20:59:40Z")
Using pattern matching for `if let` / `guard let` is actually in the commonly rejected proposals list. > [Use pattern-matching in `if let` instead of optional-unwrapping](https://forums.swift.org/t/obsoleting-if-let/1301/4): We actually tried this and got a lot of negative feedback, for several reasons: (1) Most developers don't think about things in "pattern matching" terms, they think about "destructuring". (2) The vastly most common use case for `if let` is actually for optional matching, and this change made the common case more awkward. (3) This change increases the learning curve of Swift, changing pattern matching from being a concept that can be learned late to something that must be confronted early. (4) The current design of `if case` unifies "pattern matching" around the `case` keyword. (5) If a developer unfamiliar with `if case` runs into one in some code, they can successfully search for it in a search engine or Stack Overflow. ---
**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:** [October 12, 2021, 11:32am UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437/15 "2021-10-12T11:32:39Z")
i'd also add a fix for CharacterSet: rename to what it actually is "UnicodeScalarSet", and add a temporary alias "typealias CharacterSet = UnicodeScalarSet" along with deprecation warnings prompting users to fix the name. later on if needed we can reuse CharacterSet name for some proper `Set`. ---
**Author:** ![AlexisQapa](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alexisqapa/32/7159_2.png) [@AlexisQapa](https://forums.swift.org/u/AlexisQapa)\ **Post date:** [October 12, 2021, 12:29pm UTC](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437/16 "2021-10-12T12:29:02Z")
Could this be an opportunity to revisit [Support use of an optional label for the first trailing closure](https://forums.swift.org/t/support-use-of-an-optional-label-for-the-first-trailing-closure/36371) and the APIs which would benefit from it ?