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

[Douglas_Gregor]

@Dante-Broggi

Thus I believe @concurrent to be stronger (and possibly strictly stronger) than @sendable .
However, I am uncertain what a correct response to this discrepancy would be.

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/@sendablenaming to line up, I think@concurrent` remains the better name for the attribute.

@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 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 tend to agree with you. As I've noted before and has been mentioned here, I am not at all concerned about types that start out being Sendable and then add some reference-type-ish field that makes them not Sendable. We have tools that catch it, and one has almost surely also broken value semantics with such a change, which will be the bigger surprise.

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

@Paul_Cantrell

What is @_marker , really? The proposal sketches out the loose meaning clearly enough, but it’s not quite clear why it needs to exist at all, or what it really means in practice. Is the import nothing more than the fact that Sendable is a compile-time-only type, and the compiler doesn’t emit any runtime support for it? Is it thus purely optimization, or is there a reason why a Sendable type can’t exist at runtime? Are there other types that have similar problems, and should @_marker be a public feature?

It's an important optimization, because the vast majority of types will conform to Sendable one way or another. It also makes it possible to introduce Sendable conformances in a manner that can be backward-deployed.

I think this is a good feature to make public at some point in the future, because there are undoubtedly other semantic tags we might want later (e.g., the ValueSemantics protocol idea that came up in earlier pitches).

@Paul_Cantrell

The spelling of @unchecked Sendable reads clearly enough, which is the main concern for this proposal, but it raises questions about annotations on protocol conformances. Is there some generality here we need to consider — in terms of user mental model, in terms of language capability? Or is this entirely a syntactic one-off, and developers should treat @unchecked Sendable as a single non-decomposable thought, much like @private(set) ? What precedent does this create, if any? (Are there any per-conformance annotations in the language already?)

The language does not have per-conformance annotations yet, although the idea has come up for a couple of other reasons:

• @available on conformances is a recent addition (Swift 5.4), and is currently inferred from the availability of the extension. We could narrow this to an annotation on the specific conformance that has availability.
• @retroactive on a conformance could acknowledge that a conformance is in neither the original type's module nor the protocol's module. Retroactive conformances can cause of some confusion, so there's a possible future where folks want to know about them and mark them as such explicitly.
• Actors pitch #4 has a "future direction" for isolated conformances.
• Scoped conformances could put access control on the specific conformance.

@Patrick_Smith

Instead of having implicit conformance, when you pass a non- Sendable value to where one is expected (say to an actor), could Xcode offer a fix-it to add it for you?

The compiler can generate Fix-Its to help migrate code, and IDEs or other tools can help you apply those Fix-Its.

Doug