# 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:** 18

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [March 3, 2021, 6:50pm UTC](https://forums.swift.org/t/se-0302-second-review-sendable-and-sendable-closures/45253/18 "2021-03-03T18:50:22Z")

</div>

> [@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.)

If this is agreed, then it simplifies our reasoning greatly regarding the possible risks/benefits of implicit conformance to `Sendable`:

What’s the possible harm of implicit conformance where the author hasn’t thought about it? If the rules are sound surrounding which value types can conform via the “checked conformance” route, the only drawback I can see is that future changes to the type could accidentally take away the conformance. In that case, an end user could always add it back with an “unchecked” conformance. This seems strictly better than the alternative of not conforming at all.

---

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