Ep. 43 with Holly Borla

If there's one thing that people take away from listening to this episode, it's that it is fully within your control when you decide when to tackle eliminating data races from your code.

there's something really a little bit subtle in what you just said then, which is the difference there between Swift 6, the compiler, and Swift 6, the language mode.
...
The Swift 6 compiler is just the first compiler version to offer the Swift 6 language mode. But when you start using a Swift 6 tool chain that has this new compiler, your existing code will continue to build in the language mode it's already using. So that might be Swift 4, Swift 4.2, or for most of you, it's probably Swift 5. And then when you decide to opt in, you can migrate your project to the Swift 6 language mode, either in your build settings or by changing your package manifest. And what that will do is it will start passing 6 to the Swift dash version flag, which is what configures the language mode. So when you start using the Swift 6 compiler, if you don't already have the complete concurrency checking flag enabled, you're not going to suddenly start seeing any data race issues in your project that will only come once you decide to migrate to the new language mode.

So if you want to migrate your code to Swift 6, it is not a problem if none of your dependencies have migrated to Swift 6. And then on the flip side, if one of your dependencies migrates to Swift 6, that does not mean you need to migrate. You don't need to make any changes until you decide to migrate your code to the Swift 6 language mode.

You should think about it in two different steps.

The first step is migrating to the Swift 6 language mode, which is, you know, addressing those data race safety errors that you get in your code with whatever library APIs you're currently using for concurrency, whether that's dispatch or whether you're primarily using the concurrency library, you know, that comes with Swift. Migrating to the Swift 6 language mode should not be like a major refactoring task in your code base. You don't need to go replace all of your dispatch queues with actors and you don't need to make major changes to the logic in your code unless, you know, that logic is prone to data races, of course.

And then separately, once you have eliminated data races from your code and you're getting the validation from the compiler, then you can actually go in and strategically, if you want to, replace uses of other concurrency primitives with, you know, the built-in language features like async await and actors. So I definitely view those as two different steps as part of like modernizing your app for data race safety and for concurrency.