An Implementation Model for Rational Protocol Conformance Behavior

[dabrahams (Dave Abrahams)]

@Douglas_Gregor

However, changing the identity of a type based on the set of conformances visible at the point of use is, to me, untenable. It would mean that if you added a new protocol P to your own module, then made String conform to P, you could no longer use some other module’s API that takes an array of String (because now the arrays have different types).

That's not actually the model I suggest we use. As I see it, there are two aspects to type

• Nominal type identity, e.g. “Swift.Set<A.X>” or “A.X” (where A is a module)
• Conformance set, e.g. {how A.X conforms to Hashable, how Swift.Set<A.X> conforms to Equatable}

When code expresses a requirement that two types are the same, it means:

1. the nominal type identities are equal
2. the conformance sets are non-conflicting

Two conformance sets conflict when they indicate the same nominal type conforms to a given protocol in two different ways.

In this model,

• In your example, the conformance of String to P in my own module does not prevent an Array<String> created there from interoperating with any other APIs.
• In my example, you could call doSomething() on the value produced by B.uniqueXs, but only by passing it through a context (module) where X does not conform to Equatable, and thus the concept of “unique Xs” has no meaning.

This model generalizes to scoped conformances this way for your example: if P is public but String: P is internal, another module could declare a different String: P conformance. Only then would that module's APIs involving String become incompatible with those from the module where the first conformance was defined.