# \[Pitch 2\] Staging in Sendable checking **URL:** \ **Category:** Pitches\ **Created:** [September 28, 2021, 5:51pm UTC](https://forums.swift.org/t/pitch-2-staging-in-sendable-checking/52413 "2021-09-28T17:51:10Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![beccadax](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/beccadax/32/34217_2.png) [@beccadax](https://forums.swift.org/u/beccadax)\ **Post date:** [September 28, 2021, 5:51pm UTC](https://forums.swift.org/t/pitch-2-staging-in-sendable-checking/52413/1 "2021-09-28T17:51:11Z")
Hey folks, A couple weeks ago, @Douglas_Gregor [pitched some changes which tried to tackle](https://forums.swift.org/t/pitch-staging-in-sendable-checking/51341) some of the problems involved in adopting `Sendable` checking in a module when some of your clients or dependencies may not have updated yet. I had some concerns about how that pitch’s approach might break or hide bugs when modules were eventually updated, as well as with how Objective-C libraries would be able to control the sendability of their types. Doug agreed that these might be issues, so he asked me to [write up a new pitch incorporating solutions for them](https://gist.github.com/beccadax/c05836087cd1e5a96183b80ae1f1c16e). The tl;dr is: - `@predatesConcurrency` is still roughly as Doug had it, except that it also covers global actor attributes, and Objective-C declarations are imported as predating concurrency. - When you import something that should be `Sendable` but the module has not been updated to make it `Sendable` yet, you can work around this by using `@Sendable import` to silence concurrency diagnostics related to that module. When that module later updates, you’ll either get a warning suggest you remove `@Sendable` (if all is well) or you’ll get warnings about any concurrency bugs revealed by the module’s update (but they will not be hard errors, so you can keep building your project with the bugs it already had until you find time to fix them). - You can mark Objective-C type declarations with ` __attribute__ ((swift_attr(“@Sendable”)))` to make them `Sendable`, or ` __attribute__ ((swift_attr(“@_nonSendable”)))` to give them an unavailable `Sendable` conformance (like Doug discussed in [Improving Sendable](https://forums.swift.org/t/improving-sendable/52377) yesterday). It should be possible to use Clang pragmas to provide a region-based auditing experience similar to nullability annotations. I’d love to hear your feedback on this new approach. **Edit** : In response to feedback, we'll be going back to `-warn-concurrency` and using `@predatesConcurrency import` instead of `@Sendable import`. ---
**Author:** ![lukasa](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lukasa/32/1232_2.png) [@lukasa](https://forums.swift.org/u/lukasa)\ **Post date:** [September 29, 2021, 9:04am UTC](https://forums.swift.org/t/pitch-2-staging-in-sendable-checking/52413/2 "2021-09-29T09:04:08Z")
These seem like very sensible additions to me, +1. ---
**Author:** ![benrimmington](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/benrimmington/32/695_2.png) [@benrimmington](https://forums.swift.org/u/benrimmington)\ **Post date:** [September 29, 2021, 9:20am UTC](https://forums.swift.org/t/pitch-2-staging-in-sendable-checking/52413/3 "2021-09-29T09:20:58Z")
> Enable Swift 6 mode or the `-strict-concurrency` flag. This causes new errors or warnings to appear when `Sendable` constraints are violated. How is the `-strict-concurrency` flag related to the existing `-warn-concurrency` flag? Could the new flag be named `-warn-concurrency-strict` instead? > **Note** : In the past, Foundation has provided macros with an `NS_` prefix for working more easily with ClangImporter features. However, Foundation is not part of the Swift Evolution process, so adding macros for these new features is out of scope for an Evolution proposal. Could these macros be provided in a `usr/include/swift.h` file, in the toolchain or SDKs? The [generated](https://github.com/apple/swift/blob/main/lib/PrintAsObjC/PrintAsObjC.cpp) headers (for bridging) also have some useful macros. ---
**Author:** ![beccadax](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/beccadax/32/34217_2.png) [@beccadax](https://forums.swift.org/u/beccadax)\ **Post date:** [September 30, 2021, 1:01am UTC](https://forums.swift.org/t/pitch-2-staging-in-sendable-checking/52413/4 "2021-09-30T01:01:21Z")
> [@benrimmington](#): > > How is the `-strict-concurrency` flag related to the existing `-warn-concurrency` flag? Same thing, renamed because we do emit some concurrency warnings even without the “-warn-concurrency” flag. (I’m not married to this change.) ---
**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\ **Post date:** [October 7, 2021, 10:31pm UTC](https://forums.swift.org/t/pitch-2-staging-in-sendable-checking/52413/5 "2021-10-07T22:31:28Z")
Thank you for working on this, I have a couple of thoughts: - I recommend updating the introduction to also talk about global actors, alongside `Sendable`, because this proposal now covers both. - I don't think you need to mention C++ headers; that's exciting but unrelated. - I'm not sure how much benefit there is to renaming `-warn-concurrency` to `-strict-concurrency`, given that the former is already availability in Swift 5.5, but I don't feel strongly about it. - Your full/strict/minimal categorization is spot on, thank you! - For `@predatesConcurrency`, I think we want to spell out how the type of an entity is transformed when mangling and when the entity is referenced from a minimal context. - `@Sendable import` is really nice as a suppression mechanism. I'm wondering if this should be generalized to a `@predatesConcurrency` import? As in, always treat references to entities in this imported module as "minimal" and perform the transformations described above? - All of the ObjC stuff looks very well thought-out to me