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

<div class="post-metadata">

**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\
**Post date:** [March 4, 2021, 3:57pm UTC](https://forums.swift.org/t/se-0302-second-review-sendable-and-sendable-closures/45253/35 "2021-03-04T15:57:34Z")

</div>

> [@Douglas\_Gregor](#):
>
> 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.

On the other hand, I think it'd be good fight back against the urge to wordsmith and keep the names aligned. Other unnecessarily different wordings in the language for the same concept, like `mutating`/`inout` and `consuming`/`owned` for `self` vs. other arguments, or `class`-in-protocols-and-classes-but-`static`-everywhere-else for type-level methods, create barriers for learning the language.  
(Calling any of this "concurrent" also wrinkles my concurrency-vs-parallelism pedant nose; I know it's a lost cause, but it's not concurrency we're making safe, but parallel execution. A single-core concurrent runtime wouldn't need most of this, after all.)

---

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