# \[Accepted\] SE-0302: Sendable and @Sendable closures **URL:** \ **Category:** Announcements\ **Tags:** concurrency\ **Created:** [March 16, 2021, 6:57pm UTC](https://forums.swift.org/t/accepted-se-0302-sendable-and-sendable-closures/45786 "2021-03-16T18:57:28Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [March 16, 2021, 6:57pm UTC](https://forums.swift.org/t/accepted-se-0302-sendable-and-sendable-closures/45786/1 "2021-03-16T18:57:28Z")
The [second review](https://forums.swift.org/t/se-0302-second-review-sendable-and-sendable-closures/45253) of [SE-0302](https://github.com/apple/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md) has concluded. Feedback in the second round of review was generally positive. There was a fair amount of discussion about the new names, and people seemed to generally approve of the name `Sendable` for the protocol. Consensus was weaker about the name `@sendable` for the function-type attribute; the Core Team discussed this and decided to steal an idea from [Matthew Johnson](https://forums.swift.org/t/pitch-4-concurrentvalue-and-concurrent-closures-evolution-pitches/44446/4) and [rename the attribute to `@Sendable`](https://forums.swift.org/t/se-0302-second-review-sendable-and-sendable-closures/45253/62). This name better emphasizes the core idea of the attribute (that so-modified function values have to conform to `Sendable`, and thus their captures must, too), and it also aligns with an interesting future direction (to allow similar protocol-based constraints on specific function types). The review was briefly extended, and feedback on that rename was strongly positive. Accordingly, SE-0302 is **accepted** with that modification. Thank you for helping make Swift a better language. John McCall Review Manager ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [March 16, 2021, 8:11pm UTC](https://forums.swift.org/t/accepted-se-0302-sendable-and-sendable-closures/45786/2 "2021-03-16T20:11:15Z")
> [@John\_McCall](#): > > Accordingly, SE-0302 is **accepted** with that modification. Did the core team discuss or have clarifications regarding the point raised during review about implicit conformance for frozen types? The proposal text reads: > For non-public, non-frozen structs and enums, the Sendable conformance is implicitly provided [...] > Public non-frozen structs and enums do not get an implicit conformance, because doing so would present a problem for API resilience What is the behavior proposed/accepted here for non-public frozen structs and enums, and for public frozen structs and enums? The first sentence above implies that _only_ non-public, non-frozen structs and enums would have implicit conformance, but the rationale given in the second sentence about problems for API resilience suggests that _only_ public, non-frozen structs and enums would _not_ get implicit conformance. The text does not exhaustively switch over all the possible combinations here, if you will. ---
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [March 16, 2021, 8:43pm UTC](https://forums.swift.org/t/accepted-se-0302-sendable-and-sendable-closures/45786/3 "2021-03-16T20:43:53Z")
I've asked Doug to chime in, but I believe the answer is that a type can have a conformance to `Sendable` potentially inferred if it is not publicly ABI-exposed (that is, not `public`, `open`, or `@usableFromInline`) _or_ if it is a `frozen` `struct` or `enum`. If that seems sufficiently clarifying, we can update the proposal. ---
**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 17, 2021, 4:15am UTC](https://forums.swift.org/t/accepted-se-0302-sendable-and-sendable-closures/45786/4 "2021-03-17T04:15:32Z")
I put up a small pull request with this clarification: [[SE-0302] Clarify inference for non-public structs and enums and frozen public structs and enums by DougGregor · Pull Request #1303 · apple/swift-evolution · GitHub](https://github.com/apple/swift-evolution/pull/1303) Doug ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [March 17, 2021, 4:35am UTC](https://forums.swift.org/t/accepted-se-0302-sendable-and-sendable-closures/45786/5 "2021-03-17T04:35:37Z")
@Douglas_Gregor, was there any movement or core team feedback since the review period in terms of the following items raised by @Joe_Groff, @orobio, and me which you had responded favorably to? > [@SE-0302 (second review): Sendable and sendable closures](https://forums.swift.org/t/se-0302-second-review-sendable-and-sendable-closures/45253/26): > > > [@SE-0302 (second review): Sendable and sendable closures](https://forums.swift.org/t/se-0302-second-review-sendable-and-sendable-closures/45253/18): > > > > > > [@SE-0302 (second review): Sendable and sendable closures](https://forums.swift.org/t/se-0302-second-review-sendable-and-sendable-closures/45253/13): > > > > > > > > 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. > > > [@SE-0302 (second review): Sendable and sendable closures](https://forums.swift.org/t/se-0302-second-review-sendable-and-sendable-closures/45253/5): > > > > 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. > > [...] > > > [@SE-0302 (second review): Sendable and sendable closures](https://forums.swift.org/t/se-0302-second-review-sendable-and-sendable-closures/45253/7): > > > > 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. ---
**Author:** ![MutatingFunk](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mutatingfunk/32/984_2.png) [@MutatingFunk](https://forums.swift.org/u/MutatingFunk)\ **Post date:** [March 27, 2021, 10:54am UTC](https://forums.swift.org/t/accepted-se-0302-sendable-and-sendable-closures/45786/6 "2021-03-27T10:54:00Z")
> [@John\_McCall](#): > > This name better emphasizes the core idea of the attribute (that so-modified function values have to conform to `Sendable` , and thus their captures must, too), and it also aligns with an interesting future direction (to allow similar protocol-based constraints on specific function types). Interestingly, the idea of a function type conforming to a protocol is already expressible, it just doesn't compile: `((String) -> Int) & Sendable` This admittedly reads very poorly, so maybe it's for the best this isn't going to be the primary way of expressing the constraint. But it would intuitively make sense that this syntax could work, at least with marker protocols, and perhaps allow for Sendable-closure typealiases. ---
**Author:** ![kirilltitov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/kirilltitov/32/4182_2.png) [@kirilltitov](https://forums.swift.org/u/kirilltitov)\ **Post date:** [March 27, 2021, 2:10pm UTC](https://forums.swift.org/t/accepted-se-0302-sendable-and-sendable-closures/45786/7 "2021-03-27T14:10:18Z")
I think left part might be interpreted as a tuple of one function type :) However if you express function type as a typealias, it might be legit then ---
**Author:** ![jayton](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jayton/32/5592_2.png) [@jayton](https://forums.swift.org/u/jayton)\ **Post date:** [March 27, 2021, 10:04pm UTC](https://forums.swift.org/t/accepted-se-0302-sendable-and-sendable-closures/45786/8 "2021-03-27T22:04:58Z")
By design, tuples of one item are not expressible in Swift and if one should somehow arise, it would be considered identical to the one element type. A good reason for this is that it allows parentheses to be used unambiguously in type expressions, and this need already exists for cases like `(() -> Void)!`