# SE-0302 (second review): Sendable and sendable closures

**URL:** <https://forums.swift.org/t/se-0302-second-review-sendable-and-sendable-closures/45253>\
**Category:** Proposal Reviews\
**Tags:** concurrency\
**Created:** [March 3, 2021, 3:54am UTC](https://forums.swift.org/t/se-0302-second-review-sendable-and-sendable-closures/45253 "2021-03-03T03:54:18Z")\
**Posts on this page:** 1\
**Showing post:** 26

<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:** [March 4, 2021, 6:04am UTC](https://forums.swift.org/t/se-0302-second-review-sendable-and-sendable-closures/45253/26 "2021-03-04T06:04:55Z")

</div>

> [@Dante-Broggi](#):
>
> Thus I believe `@concurrent` to be stronger (and possibly strictly stronger) than `@sendable` .  
> However, I am uncertain what a correct response to this discrepancy would be.

I agree that `@concurrent` is stronger, and I also think it is generally more understandable and meaningful: a `@concurrent` function can be executed concurrently, whether with itself or with respect to the place it was formed. That implies that it conforms to `Sendable`.

As much as I would want the `Sendable`/@sendable`naming to line up, I think`@concurrent` remains the better name for the attribute.

> [@xwu](#):
>
> > [@Joe\_Groff](#):
> >
> > If we also say that `extension Sendable` extensions are not allowed to declare members, that should contain that effect,
> 
> I think it makes a lot of sense that a “marker” protocol can’t make new APIs appear on types, even via extensions. (Users could still, of course, create a protocol refining a marker protocol and have those types adopt that conformance.)

I agree that this makes a lot of sense, and am happy to ban such extensions.

> [@orobio](#):
>
> Or will explicit conformance to the Sendable protocol be required?:
> 
> ```swift
> struct MyStruct: MyProtocol, @unchecked Sendable {}
> 
> ```
> 
> I think the latter is the clearest option.

I agree that the latter is the clearest option, and the only one we should support.

> [@xwu](#):
>
> I think that if a `struct` or `enum` is provably safe to send across concurrency domains, and we buy the justification for implicit conformance for _this_ protocol as opposed to, say, `Hashable` , then it should apply to _public and non-public_ , _frozen and non-frozen_ structs and enums.

I tend to agree with you. As I've noted before and has been [mentioned here](https://forums.swift.org/t/se-0302-second-review-sendable-and-sendable-closures/45253/10), I am not at all concerned about types that start out being `Sendable` and then add some reference-type-ish field that makes them not `Sendable.` We have tools that catch it, and one has almost surely also broken value semantics with such a change, which will be the bigger surprise.

> [@xwu](#):
>
> I should raise again the point about considering whether we ought to align with Rust in _not_ conforming the unsafe pointer types to `Sendable` in the context of this _implicit conformance_ . That would be because structs (and tuples!) that clearly are _not_ safe to conform to `Sendable` would be implicitly conformed if one of their members is an unsafe pointer.

This is a good point. The implicit `Sendable` makes it much more likely that we'll end up with a surprise with unsafe pointers.

> [@Paul\_Cantrell](#):
>
> What is `@_marker` , really? The proposal sketches out the loose meaning clearly enough, but it’s not quite clear why it needs to exist at all, or what it really means in practice. Is the import nothing more than the fact that `Sendable` is a compile-time-only type, and the compiler doesn’t emit any runtime support for it? Is it thus purely optimization, or is there a reason why a `Sendable` type _can’t_ exist at runtime? Are there other types that have similar problems, and should `@_marker` be a public feature?

It's an important optimization, because the vast majority of types will conform to `Sendable` one way or another. It also makes it possible to introduce `Sendable` conformances in a manner that can be backward-deployed.

I think this is a good feature to make public at some point in the future, because there are undoubtedly other semantic tags we might want later (e.g., the `ValueSemantics` protocol idea that came up in earlier pitches).

> [@Paul\_Cantrell](#):
>
> The spelling of `@unchecked Sendable` reads clearly enough, which is the main concern for this proposal, but it raises questions about annotations on protocol conformances. Is there some generality here we need to consider — in terms of user mental model, in terms of language capability? Or is this entirely a syntactic one-off, and developers should treat `@unchecked Sendable` as a single non-decomposable thought, much like `@private(set)` ? What precedent does this create, if any? (Are there any per-conformance annotations in the language already?)

The language does not have per-conformance annotations yet, although the idea has come up for a couple of other reasons:

- `@available` on conformances is a recent addition (Swift 5.4), and is currently inferred from the availability of the extension. We could narrow this to an annotation on the specific conformance that has availability.
- `@retroactive` on a conformance could acknowledge that a conformance is in neither the original type's module nor the protocol's module. Retroactive conformances can cause of [some confusion](https://forums.swift.org/t/retroactive-conformances-vs-swift-in-the-os/14393), so there's a possible future where folks want to know about them and mark them as such explicitly.
- [Actors pitch #4](https://forums.swift.org/t/pitch-4-actors/45215) has a "future direction" for isolated conformances.
- [Scoped conformances](https://forums.swift.org/t/scoped-conformances/37159) could put access control on the specific conformance.

> [@Patrick\_Smith](#):
>
> Instead of having implicit conformance, when you pass a non- `Sendable` value to where one is expected (say to an actor), could Xcode offer a fix-it to add it for you?

The compiler can generate Fix-Its to help migrate code, and IDEs or other tools can help you apply those Fix-Its.

Doug

---

_[View the full topic](https://forums.swift.org/t/se-0302-second-review-sendable-and-sendable-closures/45253)._