{"id":44177,"date":"2024-07-22T14:15:47","date_gmt":"2024-07-22T18:15:47","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=44177"},"modified":"2024-09-23T14:05:15","modified_gmt":"2024-09-23T18:05:15","slug":"swift-6-announced","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/07\/22\/swift-6-announced\/","title":{"rendered":"Swift 6 Announced"},"content":{"rendered":"

What’s new in Swift<\/a>:<\/p>\n

We’ll briefly go through a history of Swift over the past decade, and show you how the community has grown through workgroups, expanded the package ecosystem, and increased platform support. We’ll introduce you to a new language mode that achieves data-race safety by default, and a language subset that lets you run Swift on highly constrained systems. We’ll also explore some language updates including noncopyable types, typed throws, and improved C++ interoperability.<\/p><\/blockquote>\n\n

Migrate your app to Swift 6<\/a>:<\/p>\n

\n

Experience Swift 6 migration in action as we update an existing sample app. Learn how to migrate incrementally, module by module, and how the compiler helps you identify code that's at risk of data races. Discover different techniques for ensuring clear isolation boundaries and eliminating concurrent access to shared mutable state.<\/p>\n<\/blockquote>\n\n

Explore Swift performance<\/a>:<\/p>\n

Discover how Swift balances abstraction and performance. Learn what elements of performance to consider and how the Swift optimizer affects them. Explore the different features of Swift and how they’re implemented to further understand the tradeoffs available that can impact performance.<\/p><\/blockquote>\n\n

Demystify explicitly built modules<\/a>:<\/p>\n

\n

Explore how builds are changing in Xcode 16 with explicitly built modules. Discover how modules are used to build your code, how explicitly built modules improve transparency in compilation tasks, and how you can optimize your build by sharing modules across targets.<\/p>\n<\/blockquote>\n\n

Paul Hudson<\/a> (list<\/a>):<\/p>\n

2024 is Swift’s 10th anniversary, and for the last five of those years we’ve had no major-version Swift updates – literally half of Swift’s life has been 5.0 through to 5.10.<\/p>

This is more common than you might think. In fact, several major programming languages have some kind of release that takes significantly longer than all others: Python 3 took years to arrive, PHP 6 took so long the team bailed out and jumped straight to PHP 7, and Perl 6 dragged on so much that it ended up evolving into a different language called Raku.<\/p>

Swift last had major breaking changes back in Swift 3, but when enabled in full Swift’s own v6 has the potential to make Swift 3 look like a walk in the park. This is partly because of new changes, but partly also because many features added in recent Swift versions have been hidden behind feature flags that will be enabled by default in Swift 6.<\/p><\/blockquote>\n\n

Migrating to Swift 6<\/a>:<\/p>\n

\n

Swift’s concurrency system, introduced in Swift 5.5, makes asynchronous and parallel code easier to write and understand. With the Swift 6 language mode, the compiler can now guarantee that concurrent programs are free of data races. When enabled, compiler safety checks that were previously optional become required.<\/p>\n

Adopting the Swift 6 language mode is entirely under your control on a per-target basis. Targets that build with previous modes, as well as code in other languages exposed to Swift, can all interoperate with modules that have been migrated to the Swift 6 language mode.<\/p>\n<\/blockquote>\n\n

Joe Heck<\/a>:<\/p>\n

\n

There is a lot of great stuff coming in the Swift programming language. I love the focus and effort on validating data-race safety<\/a>, and is probably the feature set that I’ll spend the most time with. But my favorite new tidbit? Swift 6 now supports a Linux SDK and the ability to compile a stand-alone, statically linked binary.<\/p>\n<\/blockquote>\n\n

Alex Grebenyuk<\/a>:<\/p>\n

\n

In recent years, there’ve been some questionable changes, the latest one being Data Race Safety<\/a> in its current form in Xcode 16 beta.<\/p>\n

[…]<\/p>\n

If you want to migrate a large codebase to support Swift 6 mode, you need to fix thousands of compiler warnings that become errors once you enable this mode. For example, if you have any global variables, they are now errors.<\/p>\n

[…]<\/p>\n

In the ideal world, I would love to have more granular control over the types of warnings and errors the compiler produces, depending on what you can tolerate in your project. If data race safety is a compelling enough feature, people will enable it. There are also questions about whether it should<\/em> be enabled by default and whether its current design can allow it to be enabled by default considering the lack of progressive disclosure.<\/p>\n

[…]<\/p>\n

Speaking about compile time, one of Swift’s original premises was that it was “fast,” and you would expect it to apply to the compile time. However, with the current slow compilation, developers have to go to extreme lengths to work this around, including reinventing header files by creating protocol-only modules, which Swift was designed to eliminate. If there was a way to disable some of the language features to improve compile time, I would do it in an instant. I’m bringing this up because I wonder what the impact of data race safety is going to be, especially once it gets upgraded with more advanced techniques for eliminating false positives.<\/p>\n<\/blockquote>\n\n

Alex Grebenyuk<\/a>:<\/p>\n

For context, it took me months and multiple releases to get this ~4K lines of code somewhat compatible with Sendable and Swift 6. And I now have to revert my concurrency changes in Pulse from last week because I broke some stuff.<\/p>

I’m farily certain no existing large size codebase will ever be able to fully adopt Swift Concurrency Checking and Swift 6. I would also expect a short-term rise in concurrency bugs in iOS apps.<\/p><\/blockquote>\n\n

See also: Jon Reid: A Conversation With Swift 6 About Data Race Safety<\/a>.<\/p>\n\n

Heath Borders<\/a>:<\/p>\n

I really love Swift the language, but if I had my way, Twitch would only have switched to Swift 2-3 years ago when static linking was easily available.<\/p>

I got a lot of pressure from other devs to switch back in 2018, so we did, but we had a modularized codebase in Objective-C that we had to demodulalize in Swift bc of no static linking back then. Our clean build times used to be 90 seconds, and now it’s 8 minutes.<\/p>

[…]<\/p>

People would be mad if we were still in Objective-C, but I think that’s bc they’d see all the cool stuff at WWDC and wouldn’t be able to use any of it. They’d rightly think they were falling behind the industry. They wouldn’t be as marketable in other jobs.<\/p>

The main reason for Swift is because everyone else is using it.<\/p><\/blockquote>\n\n

Helge Heß<\/a>:<\/p>\n

\n

No, it is because of:<\/p>\n

> fighting the direction of the platform, and fighting Apple is generally a losing game<\/p>\n

This is IMO not rooted in preferences of developers.<\/p>\n

A big issue here is that Apple ties features to the language (and unlike ObjC, Swift has no FFI). The Apple platform developer tooling is a closed system and Apple exploits that to lock devs into their own things over alternatives, regardless of quality.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n