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.
The Core Team did regard these changes as “too expensive”, 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.
- Original proposal
- Original review thread
- Revisiting attempt upon Swift 4
- Expectation from Swift 5 user
- Latest call from the Swift 6 thread
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 addressed:
- Chris Lattner’s comment on SE-0296 amendment
- SE-0296 amendment acceptance note
- Another attempt to overload
throws: Optional Throws
Last week, Jordan Rose (@jrose) pitched to remove the implicit initialization of Optional variables and received heated discussion, including suggestions on extending the pitch to include
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:
In fact, this piece of change has already been pitched four times since 2017. It’s time to get it fixed now.
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.