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

[Joe_Groff]

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