Requiring Sendable in protocols

I’m designing an asynchronous API in the Swift 5.5 beta, starting with protocols. I’m trying to follow the rule that you should not impose irrelevant constraints, but I’m not sure whether I should require Sendable for relevant associated types.

To be clear, my protocol doesn’t inherently do anything that would require Sendable. I’m expecting a vast number of generic functions that would, however. These functions need the assurance that a result can’t change at any point in time.

Should I leave requiring Sendable to callers, or anticipate the requirement?

If the protocol does not inherently imply Sendable, then the mere existence of a generic algorithm that would does not mean you should refine Sendable.

As an example, consider Collection. Collection does not refine Hashable: Swift does not assert that a Collection is always Hashable. This is because it's not naturally in the behaviour set of a Collection to be Hashable. However, it's totally possible for an algorithm to require a hashable collection. The existence of such a thing does not mean that we should make Collection refine Hashable: it just means that the algorithm should be generic over Collection & Hashable.

4 Likes