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.