[Pitch] BitwiseCopyable marker protocol

[Karl]

@Jumhyn

So my mental model for sendable keypaths is as though there were a suite of Sendable*KeyPath subclasses which express this additional axis for keypaths (but these subclasses are kept private to avoid exploding the number of classes we actually need to deal with)

Grammatically it might look like you're expressing "some Sendable subclass of KeyPath", but once you look more closely it becomes clear that that mental model can only be a macroscopic approximation, and that reality involves quantum effects:

1. It isn't actually possible to express this relationship using class sub-typing: WritableKeyPath & Sendable is a subtype of WritableKeyPath, KeyPath, and KeyPath & Sendable. However, KeyPath & Sendable and WritableKeyPath do not have any sub-typing relationship between them. There is no line which connects those dots if you view them as concrete Sendable{X}KeyPath types.

2. The dynamic type is discoverable at runtime, regardless of whether it is private. So we can just directly ask and see that sendable and non-sendable key paths in fact have the same type.

So really the only explanation I can see is that, when we're talking about keypaths, the & Sendable constraint refers to the value, not the type. It's not "some Sendable subclass of KeyPath", it's "some subclass of KeyPath, and the value is Sendable".

Regex has a similar problem to KeyPath. But since Sendable constraints can be applied orthogonally to class sub-typing, there is the possibility that we could use a similar Regex & Sendable construct there.

Anyway, it's not directly relevant to this thread to get in to the details. Suffice to say, Sendable is pretty weird as far as protocols go. If we dropped the "protocol" terminology and instead called it a "sendability constraint" or something along those lines, it's unlikely to hurt (and quite possibly may help) understanding.