Progress toward the Swift 6 language mode

At one point Apple announced forthcoming 64-bit support for Carbon but it was never shipped (on either PPC or x86). I've heard rumors that some developers got beta versions of it but it was pulled prior to WWDC 2007 when Leopard was announced. Large portions of Carbon were ported to 64-bit architectures but a lot of it was reserved for Apple's internal use (as AppKit called into Carbon for a lot of functionality) whereas certain other portions (mostly non-GUI stuff) were available for third-party use. (This old documentation shows which pieces did or did not end up being public API.)

Even some UI bits could still be hanging around, although probably not much. HIToolbox.framework still exists in Sonoma! Over the years AppKit has relied less and less on Carbon. But the Menu Manager was still being used internally to draw menus as recently as Ventura! It's only now in Sonoma we finally have pure Cocoa menus. Hence this entry in the AppKit Release Notes for Sonoma:


I'm not sure a language mode would need to be involved with that; we could just deprecate the setter.


But as long as it exists and is callable, they aren't necessarily concurrency-safe, are they?

even if the setter is deprecated, won’t it still produce concurrency warnings?

1 Like

We could have it lock internally or even just trap on attempts to set it to a different value, if the setter's really never used.

If you're interested in talking about that, it should probably get its own thread.


What a great talk, thanks for sharing. I was very impressed by how well structured it was and how fluidly it transitioned from topic to topic. I feel like I learned a lot in a short 45 minutes!

1 Like

@jrose I have recently stumbled upon your post on the Forum regarding Opaque Pointer. There was a discussion whether correction of this problem might appear in Swift 6 and you have stated, that

I'm a little confused, is this about possible API incompatibility?

Also, if I understand this evolution proposal correctly, something similar was already implemented for Objective-C.

I've been working a lot with C dependencies lately and would love to see those opaque pointers as distinct types!


Has it already been decided whether Swift 6 will be released this year, i.e. around September 2024? Or can we expect it in 2025 at the earliest?

I'm asking because I've already seen some references to Swift 5.11, e.g. in the changelog in the Swift repo, which suggests Swift 6.0 will not come out this year.

I guess we'll all learn this around March/April 2024 at the latest when the release plan for the Swift release after 5.10 gets published, but it would be nice to be able to plan ahead.


It's not my call, of course, but given how many proposals are still underway and the fact that 5.x still has quite a bunch of fragile corners (i.e. around concurrency), I'd rather see Swift 6 coming 2025 than this year...


Yes. I hope that Swift 6 will be great, better do it right. And also as a cross platform language, the new Foundation will then maybe be fully "arrived". And the people from The Browser Company are doing great progress with Swift on Windows (also for Windows on ARM I hope).

So I guess Swift 6 will be accepted as a "true" cross platform language and with the main portion of the properties that make Rust so popular. One year or so is not too long to wait for this. :+1:


Swift 5.10 incorporates the remaining language proposals necessary for accomplishing full data isolation under strict concurrency checking. It does so conservatively, and the set of proposals under active development now in Swift evolution aim to lift some of the limitations for patterns that are diagnosed in Swift 5.10, but can be proven safe using other techniques, namely region isolation in SE-0414. Region isolation has just been accepted, and the remaining concurrency proposals for Swift 6 on the horizon are minor in nature; they're all small model tweaks that lift limitations, such as by inferring @Sendable on actor isolated closures or extending rules that are already part of today's concurrency semantic model.

At this point, these changes are all additive changes that make the model easier to use, and could be included after Swift 6 is released. As such, the next release of Swift will be Swift 6.

5.11 was used as a placeholder; I will update the codebase to use 6.0 shortly.


@hborla Thank you for the information.

1 Like