The Core Team talked about this today, and we had an idea that we'd like one last bit of feedback on. We have decided to accept Sendable as the protocol name, borrowing the term of art sending from Rust for the act of sharing/moving values between different concurrency domains, which otherwise doesn't have a shortening that we believe to be acceptable. We were talking about what to call the function attribute — whether it should be something more "on the nose" for concurrency, like @concurrent, or whether it should align with the protocol name, like @sendable — when we realized that it was actually interesting to consider just using the protocol name, like @Sendable. This very neatly expresses the new capability introduced by the constraint, which is that the function value can be safely sent between concurrency domains, and thus that the function type conforms to Sendable. It also expresses the main restriction imposed by the constraint, which is that the captured values must conform to Sendable.
Grammatically, this would be a new use of user-defined attributes. For now, it would be limited to just the Sendable protocol, but in the future, we could allow this to be extended to apply to other protocols whose conformances can be autogenerated, such as Hashable or Codable. If Swift ever gains the ability to metaprogram a conformance to an arbitrary protocol, this could take advantage of that. We needn't design this feature right now; it's sufficient to see that this is a compelling future direction to take the language.
For these reasons, the Core Team is tentatively in favor of adopting the spelling @Sendable for the function type constraint in SE-0302. However, this is a novel idea which we haven't had much time to think about; more importantly, it's an idea that we haven't given the community an opportunity to think about. It would be inappropriate for us to immediately settle on it without discussion. Therefore, we are extending the period of this review until this Friday, March 12th, to allow the community to provide feedback on this new spelling.
All other aspects of SE-0302 will be accepted as proposed.