Progress toward the Swift 6 language mode

[tim1724 (Tim Buchheim)]

@Nobody1707

I seem to remember that Carbon was ported to 64-bit PowerPC, and that an x86-64 port of Carbon was announced (and might have even been available in a beta release of OS X) then canceled shortly after.

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.)

But that was just the UI layer of Carbon, I believe a few bits of the non-UI parts of Carbon might still exist on MacOS even today.

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:

• In macOS 14, menus have been reimplemented from the ground up to fully use AppKit.

[John_McCall]

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

[bbrk24]

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

[taylorswift]

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

[John_McCall]

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.

[jeremyabannister (Jeremy Bannister)]

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!

[stuchlej (Mikoláš Stuchlík)]

@hborla

Additional evolution proposals may include source-incompatible changes for Swift 6, and the Language Steering Group will evaluate such proposals on a case-by-case basis for high value to the language relative to the cost of source incompatibilities.

@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

@jrose

It’s hard to say. Swift versions apply on a per-library basis, so that you can use Swift 6 while still depending on a Swift 5 package. But what happens when the Swift 5 library vends an API that uses one of these OpaquePointer typedefs?

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.

@hborla

• SE-0384: Importing Forward Declared Objective-C Interfaces and Protocols (ImportObjcForwardDeclarations)

[Lancelotbronner (Christophe Bronner)]

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

[ole (Ole Begemann)]

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.

[mickeyl (Dr. Mickey Lauer)]

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...

[sspringer (Stefan Springer)]

@mickeyl

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.

[hborla (Holly Borla)]

@ole

Has it already been decided whether Swift 6 will be released this year

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.

@ole

I'm asking because I've already seen some references to Swift 5.11

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

[ole (Ole Begemann)]

@hborla

As such, the next release of Swift will be Swift 6.

@hborla Thank you for the information.