Difficulty designing a static requirement due to Sendable & SE-0412

I don't think this is true. Sendable is inherent for many kinds of types, including value types composed of Sendable properties, immutable final classes, actor-isolated types (including actors and global-actor isolated classes/structs), etc. However, there's a ton of Swift code out there that uses mutable reference types which are not Sendable and will never become Sendable unless they are only ever used from a specific isolation domain such as the main actor.

It is not a goal for everything to become Sendable, and I hope that the acceptance of SE-0414 helps people realize that not everything should be marked as Sendable. From my perspective, the goal is specifically to mark the values that are thread safe as such, and in some cases, put in the additional work to make types thread safe when they are already used that way in practice.

I completely agree. Sendable is explicit documentation about whether or not a type is thread safe / safe to share across isolation boundaries. It has always been the case that users of libraries need to know whether or not the types they're using are thread safe, and Sendable conformances will make finding that information much easier.

I think this is actually a consequence of using extensions as a namespace of sorts. When the enclosing type became @MainActor-isolated, so did all of these constants. I wonder if the compiler should issue a warning if you've written a static let of Sendable type in an actor-isolated context with a fix-it to insert nonisolated. You can already access the variable as if it were nonisolated from within the module, but you may very well want that to be the case outside the module as well. Perhaps this is also something that the Clang importer can do by default, which would fix these cases with NSNotification.Name.

I can't emphasize this enough. I think that feedback from Xcode 15.3 / Swift 5.10 is critical ahead of Swift 6. Everybody writes code differently, which means that different people will discover different usability issues with strict concurrency checking. Providing feedback on the forums is also a great way to build a shared understanding amongst the community about which code patterns are concurrency safe and why, which was difficult to do prior to Swift 5.10 because the design for full data isolation wasn't complete. I appreciate all of the recent discussion threads on new concurrency diagnostics in 5.10 and potential strategies for mitigating false reports of data races. Please continue to discuss your experience using strict concurrency checking in Swift 5.10!

11 Likes