@john_mccall, I think it may be important to add also the following that's mentioned in the document's revision history:
- Add implicit conformance to
Sendablefor non-public, non-frozenstructandenumtypes.
I'd like to briefly focus the review on that point. Specifically, the proposal states:
A
structorenumcan only be made to conform toSendablewithin the same source file in which the type was defined.
For non-public, non-frozen structs and enums, the
Sendableconformance is implicitly provided when conformance checking (described in the previous section) succeeds
I worry that these two rules will not compose well. Library authors who are not fully paying attention to how their value types work with concurrency may find that everything "works fine" only to neglect to vend a checked conformance [e.g., when they extract a type from a working app into a shared library], requiring users to write unchecked retroactive conformances.
I think that if a struct or enum is provably safe to send across concurrency domains, and we buy the justification for implicit conformance for this protocol as opposed to, say, Hashable, then it should apply to public and non-public, frozen and non-frozen structs and enums.
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.