[Accepted] SE-0302: Sendable and @Sendable closures

[xwu (Xiaodi Wu)]

@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?

@Douglas_Gregor

@xwu

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

I agree that this makes a lot of sense, and am happy to ban such extensions.

@orobio

Or will explicit conformance to the Sendable protocol be required?:

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.

[...]

@xwu

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.