# \[Pitch\] Staging in \`Sendable\` checking

**URL:** <https://forums.swift.org/t/pitch-staging-in-sendable-checking/51341>\
**Category:** Pitches\
**Created:** [August 19, 2021, 7:01pm UTC](https://forums.swift.org/t/pitch-staging-in-sendable-checking/51341 "2021-08-19T19:01:44Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**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:** [August 23, 2021, 7:53pm UTC](https://forums.swift.org/t/pitch-staging-in-sendable-checking/51341/13 "2021-08-23T19:53:15Z")

</div>

> [@gwendal.roue](#):
>
> In this context, I can imagine a third stage: the library author wants to delay concurrency adoption in a module (for some good reason), but wants to prevent incorrect `Sendable` inference.
> 
> Is it a scenario worth considering? What about letting the author of such a module annotate types that are known to be non-sendable, in order to prevent the compiler from inferring this conformance?

This came up in the review of SE-0302, because `Sendable` is inferred structurally for non-public struct and enum types, and there is currently no way to disable the inference. I'm inclined toward using (un)availability on the conformance to spell "this is intentionally not `Sendable`", rather than invent something new, e.g.,

```swift
public struct MyType : @available(unavailable, *) Sendable {
  var x, y: Double
  // some day we may add some shared state here
}

```

To your use case, if a module explicitly declares an unavailable `Sendable` conformance, importing modules should complain if they need `MyType` to be `Sendable`.

If every type is explicitly marked as `Sendable` or having unavailable `Sendable` conformance, then there's no observable difference in importing modules as to whether the module has adopted concurrency or not.

> [@Jumhyn](#):
>
> > [@Douglas\_Gregor](#):
> >
> > One additional tweak we could make is to produce an error when a module declares a `Sendable` conformance for a type from another module
> 
> Hm, so the Swift 6 rule would be "don't conform types you don't own to `Sendable` "? I don't think that causes major issues for inferring `Sendable` for aggregates (since the aggregate itself can just be tagged `@unchecked Sendable` ), but it would prevent the _direct_ usage of `Point3D` as `Sendable` in the case where I somehow _know_ that it is concurrency-safe and that the author of module A perhaps just forgot to add the conformance.

Oh, that's not what I meant. I don't want to ban this:

```swift
import A

// Point3D is from module A
extension Point3D: @unchecked Sendable { }

```

I want to turn it into an error if `A` adopts concurrency and doesn't make `Point3D` `Sendable`:

```swift
// module A adopts concurrency
public struct Point3D { ... } // not Sendable

```

Doug

---

_[View the full topic](https://forums.swift.org/t/pitch-staging-in-sendable-checking/51341)._