Improving Sendable

[Douglas_Gregor]

@ksluder

While SE-0302 requires a Sendable class be final unless its sendability is marked @unchecked , a subclass could be defined very far away from its superclass, perhaps even in a different module. Or the conformance could be retroactively added in an extension by a third party. @unchecked might not provide a very visible signal to the subclass author that they must do extra work to maintain the superclass’s promise of Sendability.

I definitely agree with this.

@ksluder

And declaring Sendable conformance in an extension seems generally unwise, except in the specific case of conditioning conformance on the sendability of generic parameters.

Personally, I think that declaring Sendable via an unconstrained extension should only be done from outside the module, when the defining module has not yet adopted concurrency.

@ksluder

I would like to re-evaluate modeling Sendable as a protocol, and propose an alternative in which sendable exists as a declaration modifier like public or async :

I'd like to tease apart your suggestions, because one is syntactic and the other is more semantic. The semantic suggestion addresses your concern about subclasses not knowing that they've been signed up to be Sendable by their superclass. If I take away the syntactic changes you're describing, it's:

class C2: @unchecked Sendable { } // sure, this is fine

class C3 : C2 { } // error: subclass of a Sendable class must also be explicitly marked Sendable

class C4: C2, @unchecked Sendable { } // okay!

I like this direction: it makes the Sendable requirement obvious for subclasses, so one cannot accidentally violate sendability. I'll incorporate this in the next version of the proposal.

@ksluder

Aesthetically and pedagogically, I find the existence of both : Sendable and @Sendable unfortunate.

At this point, I don't know that I would go back and change Sendable and @Sendable. I think there are generalizations where this makes sense---for example, we could allow any marker protocol to also annotate function types---but we derive a lot of benefits from Sendable being a protocol and we don't really have a syntax for saying that an arbitrary function type conforms to a protocol. Much of the syntax you show is, to me, less understandable than "Sendable is a protocol and this is what it means".

Doug