\documentclass[../generics]{subfiles}

\begin{document}

\chapter{Conformances}\label{conformances}

\IndexDefinition{invalid conformance}
\index{abstract conformance}
\IndexDefinition{concrete conformance}
\IndexDefinition{normal conformance}
\index{specialized conformance}
\index{inherited conformance}
\IndexDefinition{self conformance}
\index{specialized type}
\lettrine{C}{onformances relate} concrete types with protocols. The last chapter informally introduced conformances in substitution maps, which record the fulfillment of a conformance requirement in a generic signature. We will resume this discussion shortly, and you will see that conformances to protocols with associated types play an important role in type substitution. But first, let's understand the representation and lookup of conformances.

Formally, a conformance describes how a concrete type \emph{witnesses} each requirement of a protocol that it conforms to. There are three kinds of conformance:
\begin{enumerate}
\item An \textbf{invalid conformance} denotes that a type does not actually conform to the protocol.
\item An \textbf{abstract conformance} denotes that a type conforms to the protocol, but it is not known where this conformance was declared (\SecRef{abstract conformances}).
\item A \textbf{concrete conformance} represents a conformance with a known definition.
\end{enumerate}

Concrete conformances break down further into four sub-kinds, the first two being our primary focus for now:
\begin{enumerate}
\item A \textbf{normal conformance} declares a conformance on a nominal type or extension.
\item A \textbf{specialized conformance} results from type substitution (\SecRef{conformance subst}).
\item A \textbf{self conformance} describes a self-conforming protocol, which is only possible in a few very special cases (\SecRef{selfconformingprotocols}).
\item An \textbf{inherited conformance} describes the conformance of a subclass when the conformance was declared on the superclass (\SecRef{inheritedconformance}).
\end{enumerate}

\index{extension declaration}%
\index{nominal type declaration}%
\index{inheritance clause}%
\IndexDefinition{conformance}%
\index{protocol conformance|see{conformance}}%
\paragraph{Normal conformances.} Structs, enums and classes can conform to protocols. A normal conformance represents the \emph{declaration} of a conformance. Normal conformances are declared in the inheritance clause of a nominal type or extension:\index{horse}
\begin{Verbatim}
struct Horse: Animal {...}

struct Cow {...}
extension Cow: Animal {...}
\end{Verbatim}
The above code declares two normal conformances, $\ConfReq{Horse}{Animal}$ and $\ConfReq{Cow}{Animal}$.
Each type or \index{extension declaration}extension declaration has a list of \IndexDefinition{local conformance}\emph{local conformances}, which are the normal conformances declared on that type or extension. In the above, the struct declaration \texttt{Horse} has a single local conformance. The struct declaration \texttt{Cow} does not have any local conformances itself, but the \emph{extension} of \texttt{Cow} has one. 

Nominal type declarations have a \IndexDefinition{conformance lookup table}\emph{conformance lookup table}, which stores the local conformances of the type and any of its extensions, together with conformances inherited from the superclass, if the type declaration is a class declaration. Extension declarations do not have a conformance lookup table of their own; their local conformances are part of the \index{extended type}extended type's conformance lookup table. The conformance lookup table is used to implement global conformance lookup. The rest of the compiler does not interact directly with conformance lookup tables.

\index{declared interface type}
\index{declaration context}
\index{generic signature}
\index{unconstrained extension}
\IndexDefinition{value witness}
\IndexDefinition{value requirement}
Broken down into constituent parts, a normal conformance stores the following:
\begin{itemize}
\item \textbf{The type:} the declared interface type of the conforming context.
\item \textbf{The protocol:} this is the protocol being conformed to.
\item \textbf{The conforming context:} either a nominal type declaration (if the conformance is stated on the type) or an extension thereof (if the conformance is stated on an extension).
\item \textbf{The generic signature:} the generic signature of the conforming context. If the conformance context is a nominal type declaration or an unconstrained extension, this is the generic signature of the nominal type. If the conformance context is a constrained extension, this generic signature will have additional requirements, and the conformance becomes a conditional conformance. Conditional conformances are described in \SecRef{conditional conformance}.
\item \textbf{Type witnesses:} a mapping from each associated type of the protocol to the concrete type witnessing the associated type requirement. This is an interface type written in terms of the generic signature of the conformance. \SecRef{type witnesses} will talk about type witnesses.
\item \textbf{Associated conformances:} a mapping from the conformance requirements of the requirement signature to a conformance of the substituted subject type to the requirement's protocol. \SecRef{associated conformances} will talk about associated conformances.
\item \textbf{Value witnesses:} for each value requirement of the protocol, the declaration witnessing the requirement. This declaration is either a member of the conforming nominal type, an extension of the conforming nominal type, or it is a \index{default witness}default witness from a \index{protocol extension}protocol extension. The mapping is more elaborate than just storing the witness declaration; \ChapRef{valuerequirements} goes into the details.
\end{itemize}

\section{Conformance Lookup}\label{conformance lookup}

\IndexDefinition{global conformance lookup}
A conformance can be obtained via \emph{global conformance lookup}, an operation defined as taking a \index{protocol declaration}protocol declaration and a \IndexDefinition{conforming type}conforming type. Global conformance lookup can be understood as the action of a protocol declaration \texttt{P} on the left of a type \texttt{T}. We denote the protocol as $\pP$ to avoid confusion with the protocol \emph{type}, and use the notation $\TP$ to represent the found conformance of \texttt{T} to \texttt{P}, whatever kind of conformance it may be:\index{$\otimes$}
\[\pP\otimes\texttt{T} = \TP\]

Global conformance lookup performs a case analysis on the given conforming type, returning one of several kinds of conformance:
\begin{itemize}
\item For the declared interface type of a \index{nominal type declaration}nominal type declaration, it consults the \index{conformance lookup table}conformance lookup table, and returns a \index{normal conformance}normal conformance to the protocol, if one exists.
\item For another specialized type of a nominal type declaration, it returns a specialized conformance, as described in the next section.
\item For a type parameter, it returns an abstract conformance (\SecRef{abstract conformances}).
\item In any case not covered by the above, it returns an invalid conformance.
\end{itemize}

From a conformance $\TP$, we can obtain the conformed protocol \texttt{P} and conforming type \texttt{T}. The conforming type of a valid conformance found by global conformance lookup is canonically equal to the type that was handed to the lookup operation (the two types might differ by type sugar, so are not required to be \index{type pointer equality}equal as type pointers). We can exhibit this with a \index{commutative diagram}\emph{commutative diagram}:
\begin{quote}
\begin{tikzcd}[column sep=3cm,row sep=1cm]
\texttt{T} \arrow[r, bend left, "\text{look up conformance}"] &{\TP}\arrow[l, bend left, "\text{get conforming type}"]
\end{tikzcd}
\end{quote}
A commutative diagram is a diagram where every path with the same start and end leads to the same result. The above commutative diagram shows two pairs of paths:
\begin{enumerate}
\item Starting from a type, we look up its conformance to a fixed protocol, and get the conforming type of this conformance. This takes us back to the original type.
\item Starting from a conformance, we get its conforming type, and perform a global conformance lookup with this type and our protocol. This gives us the original conformance.
\end{enumerate}

\newcommand{\NormalConf}{\ConfReq{$\texttt{T}_d$}{P}}

So far, we've only introduced normal conformances. If $d$ is a nominal type declaration and $\texttt{T}_d$ is the declared interface type of $d$, then a normal conformance of $\texttt{T}_d$ to \texttt{P} is written as $\NormalConf$ in our notation, as its conforming type is $\texttt{T}_d$:
\[\pP\otimes\texttt{T}_d=\NormalConf\]

We will look at more equations and commutative diagrams in the next section, after a brief interlude to discuss a conceptual difficulty.

\paragraph{Coherence.} If a conformance is declared on an extension, the conforming type and the conformed protocol might be in different \index{module declaration}modules. We consider the three possibilities. First, we can conform our own type to a protocol from another module:
\begin{Verbatim}
struct MyType {...}
extension MyType: Hashable {...}
\end{Verbatim}
We can also conform a type from another module to our own protocol:
\begin{Verbatim}
protocol MyProtocol {...}
extension Int: MyProtocol {...}
\end{Verbatim}
Finally, in the most general case, both the conforming type and conformed protocol are declared in modules separate from ours. We call this a \IndexDefinition{retroactive conformance}\emph{retroactive conformance}:
\begin{Verbatim}
extension String.UTF8View: Hashable {...}
// warning: extension declares a conformance of imported type
// 'UTF8View' to imported protocol 'Hashable'; this will not
// behave correctly if the owners of 'Swift' introduce this
// conformance in the future
\end{Verbatim}
As of \IndexSwift{6.0}Swift~6, the compiler diagnoses this situation, enforcing what is sometimes known as the \index{orphan rule|see{retroactive conformance}}\emph{orphan rule} in other languages with similar capabilities. For source compatibility reasons, this is just a warning, but it ought to be an error. The \index{diagnostic!retroactive conformance}diagnostic can be silenced by explicitly stating the intent with the \texttt{@retroactive} attribute to the conformance, offering an escape hatch for this situations that warrant it (and our example certainly does not):
\begin{Verbatim}
extension String.UTF8View: @retroactive Hashable {...}
\end{Verbatim}
Retroactive conformances are problematic because they allow one to declare \index{overlapping conformance}\index{overlapping conformance|seealso{retroactive conformance}}\emph{overlapping conformances}.

The compiler rejects a conformance declaration if some existing conformance is statically visible, so this scenario cannot occur with \texttt{Int} and \texttt{Hashable} for instance, because any attempt to define a overlapping conformance will be caught. With retroactive conformances, this is no longer the case, so we cannot guarantee the \IndexDefinition{coherence}\emph{coherence} of global conformance lookup. Suppose a concrete type \texttt{K} is defined in some common module, and two unrelated modules each declare a conformance of \texttt{K} to \texttt{Hashable} unbeknownst to the other. If a module then imports all three, it becomes possible to construct two values of type \texttt{Set<K>} with incompatible hash functions; passing such a value across module boundaries will result in undefined behavior.

A similar scenario can occur with library evolution. Suppose a library author publishes the concrete type \texttt{K}, and a third party defines a retroactive conformance of \texttt{K} to \texttt{Hashable}. If the library vendor then adds their own conformance of \texttt{K} to \texttt{Hashable}, the previously-compiled client might encounter incorrect behavior at runtime.

Unfortunately, the orphan rule does not completely \index{limitation!orphan rule and subclassing}close the hole, because of class inheritance and library evolution. Consider a framework which defines an open class and a protocol:
\begin{Verbatim}
public protocol MyProtocol {}
open class BaseClass {}
\end{Verbatim}
A client might declare a subclass of \texttt{BaseClass} and conform it to \texttt{MyProtocol}, concluding this it is safe to do so because the conforming type, \texttt{DerivedClass}, is owned by the client, and thus this is not a retroactive conformance:
\begin{Verbatim}
import OtherLibrary

class DerivedClass: BaseClass {}
extension DerivedClass: MyProtocol {}
\end{Verbatim}
However, in the next version of the framework, the framework author might decide to conform \texttt{BaseClass} to \texttt{MyProtocol}. At this point, \texttt{DerivedClass} has two overlapping conformances to \texttt{MyProtocol}; the inherited conformance from \texttt{BaseClass}, and the local conformance of \texttt{DerivedClass}.

\paragraph{Future directions.} The theoretical model could one day be extended to fully support overlapping conformances. The global conformance lookup operation would need to be changed to disambiguate in the case of multiple lookup results, possibly by receiving some kind of lexical context from the caller, in addition to the type and protocol.

The runtime equivalent of a global conformance lookup is a \index{dynamic cast}\emph{dynamic cast} from a concrete type to an existential type. Dynamic casts would also need to be extended to deal with overlapping conformances.

\section{Conformance Substitution}\label{conformance subst}

Now, we will define global conformance lookup with a \index{specialized type}specialized nominal type \texttt{T}. We know from \SecRef{contextsubstmap} that \texttt{T} splits up into the \index{declared interface type}declared interface type $\texttt{T}_d$ and \index{context substitution map}context substitution map, $\Sigma$. We begin by expanding out \texttt{T} in the global conformance lookup $\pP\otimes\texttt{T}$:
\[
\pP\otimes\texttt{T} = \pP \otimes (\texttt{T}_d \otimes \Sigma)
\]
So far, we don't have any means to simplify the above expression further. However, recall that when we first introduced type substitution and substitution map composition, we defined them to not depend on order of operations. Thus, if \texttt{T} is a type and $\Sigma_1$, $\Sigma_2$, and $\Sigma_3$ are substitution maps, we showed that $(\texttt{T}\otimes\Sigma_1)\otimes\Sigma_2=\texttt{T}\otimes(\Sigma_1\otimes\Sigma_2)$, and also $(\Sigma_1\otimes\Sigma_2)\otimes\Sigma_3=\Sigma_1\otimes(\Sigma_2\otimes\Sigma_3)$. Analogously, we would like for the following to hold:
\[
\pP \otimes (\texttt{T}_d \otimes \Sigma) = (\pP \otimes \texttt{T}_d) \otimes \Sigma
\]
Now, we can simplify the right hand side, at least partially. We have $\pP\otimes\texttt{T}_d=\NormalConf$. This leaves us with the new kind of expression $\NormalConf\otimes\Sigma$ that we have not seen before; we need to apply a substitution map to a conformance. Just as applying $\Sigma$ to $\texttt{T}_d$ outputs the specialized type \texttt{T}, applying $\Sigma$ to the normal conformance $\NormalConf$ outputs a \IndexDefinition{specialized conformance}\emph{specialized conformance}, denoted $\TP$, which describes how \texttt{T} meets the requirements of \texttt{P}:
\[\pP\otimes\texttt{T}=\TP=\NormalConf\otimes\Sigma\]

The behavior of a specialized conformance $\TP$ can be specified entirely in terms of the underlying normal conformance $\NormalConf$, together with the \IndexDefinition{conformance substitution map}\emph{conformance substitution map} $\Sigma$. When \texttt{T} is not the declared interface type of some nominal type, we write $\TP$ as a notational convenience, if it is clear that $\texttt{T}=\texttt{T}_d\otimes\Sigma$ for some $\texttt{T}_d$ and $\Sigma$. In the implementation, the ``formal'' pair $\NormalConf\otimes\Sigma$ is the more primitive notion.

There is also a special case involving the identity substitution map. Suppose that the generic signature of $d$ is $G$. If the conformance substitution map is $1_G$, a specialized conformance is not constructed; substitution returns the original normal conformance:
\[
\NormalConf \otimes 1_G = \NormalConf
\]
\index{conformance substitution map}
\index{conforming type}

To make this concrete, consider the specialized type \texttt{Array<Int>}. The normal conformance $\ConfReq{Array<\ttgp{0}{0}>}{Sequence}$ is defined in the standard library. So, we have:
\begin{gather*}
\protosym{Sequence}\otimes\texttt{Array<Int>}\\
\qquad {} = \protosym{Sequence}\otimes(\texttt{Array<\ttgp{0}{0}>}\otimes\SubstMap{\SubstType{\ttgp{0}{0}}{Int}})\\
\qquad {} = (\protosym{Sequence}\otimes\texttt{Array<\ttgp{0}{0}>})\otimes\SubstMap{\SubstType{\ttgp{0}{0}}{Int}})\\
\qquad {} = \ConfReq{Array<\ttgp{0}{0}>}{Sequence}\otimes\SubstMap{\SubstType{\ttgp{0}{0}}{Int}}\\
\qquad {} = \ConfReq{Array<Int>}{Sequence}
\end{gather*}

Going backwards, the conforming type of a specialized conformance $\TP$ is defined as the conforming type of the normal conformance with the conformance substitution map $\Sigma$ applied. This is just $\texttt{T}=\texttt{T}_d\otimes\Sigma$. This fact is not \emph{completely} trivial; it makes our diagram commute:
\begin{quote}
\begin{tikzcd}[column sep=3cm,row sep=1cm]
\texttt{T} \arrow[r, bend left, "\text{conformance lookup}"] &\TP\arrow[l, bend left, "\text{conforming type}"]
\end{tikzcd}
\end{quote}
For example, the conforming type of $\ConfReq{Array<Int>}{Sequence}$ is \texttt{Array<Int>}.

\paragraph{Canonical conformances.}
\IndexDefinition{canonical conformance}
\index{canonical substitution map}
Just like types and substitution maps, specialized conformances are immutable and uniquely-allocated. A specialized conformance is \emph{canonical} if the substitution map is canonical. We compute the canonical specialized conformance from an arbitrary specialized conformance by replacing its substitution map with a canonical substitution map. Normal and abstract conformances are always canonical.

\paragraph{More about substitution.} As with substitution maps, we define the \index{output generic signature}output generic signature of a conformance. For a \index{normal conformance}normal conformance, this is the generic signature of the conforming context (the nominal itself, or an extension). For a \index{specialized conformance}specialized conformance, we take it to be the \index{output generic signature}output generic signature of the \index{conformance substitution map}conformance substitution map. We can denote the set of all conformances with output generic signature $G$ by \IndexSetDefinition{conf}{\ConfObj{G}}$\ConfObj{G}$. Now, if we have a normal conformance $\NormalConf\in\ConfObj{G}$ and a substitution map $\Sigma\in\SubMapObj{G}{G^\prime}$, then $\NormalConf\otimes\Sigma\in\ConfObj{G^\prime}$, by definition.

With this notation, we can understand how type substitution applies a substitution map to a \emph{specialized} conformance. Suppose $\Sigma^\prime\in\SubMapObj{G^\prime}{G^{\prime\prime}}$. Then, applying $\Sigma^\prime$ to the specialized conformance $\NormalConf\otimes\Sigma$ outputs a new specialized conformance with the composed substitution map:
\[(\NormalConf\otimes\Sigma)\otimes\Sigma^\prime=\NormalConf\otimes(\Sigma\otimes\Sigma^\prime)\]
This means that, for example, the expression $\pP\otimes\texttt{T}_d\otimes\Sigma\otimes\Sigma^\prime$ can be evaluated in one of several ways, corresponding to each possible placement of parentheses, but all evaluations produce the same result---a conformance to \texttt{P} with conforming type $\texttt{T}_d\otimes\Sigma\otimes\Sigma^\prime$.

Thus, we can apply substitution maps to conformances, just like we can apply them to types, and compose them with other substitution maps. To recap, we now have three ``overloads'' of \index{$\otimes$}$\otimes$ in our type substitution algebra:
\begin{gather*}
\TypeObj{G}\otimes\SubMapObj{G}{G^\prime}\longrightarrow\TypeObj{G^\prime}\\
\ConfObj{G}\otimes\SubMapObj{G}{G^\prime}\longrightarrow\ConfObj{G^\prime}\\
\SubMapObj{G}{G^\prime}\otimes\SubMapObj{G^\prime}{G^{\prime\prime}}\longrightarrow\SubMapObj{G}{G^{\prime\prime}}
\end{gather*}

\section{Type Witnesses}\label{type witnesses}

\iffalse
:
\begin{itemize}
\item The conforming type must declare a \emph{type witness} for each associated type. We will discuss type witnesses in \SecRef{type witnesses}.
\item The conforming type itself and its type witnesses must satisfy the protocol's associated requirements. We will discuss checking if requirements are satisfied in \SecRef{checking generic arguments}.
\end{itemize}

\fi

%TODO: \Request{type witness request}.

\IndexDefinition{type witness}
\index{type alias declaration}
\index{generic parameter declaration}
\IndexDefinition{associated type inference}
\index{conformance checker}
\index{value requirement}
\index{conforming type}
\index{associated type declaration}
A concrete type fulfills the associated type requirements of a protocol by declaring a \emph{type witness} for each associated type. Type witnesses are declared in one of four ways:
\begin{enumerate}
\item Via a \textbf{member type declaration} having the same name as the associated type. Usually this member type is a type alias, but it is legal to use a nested nominal type declaration as well. If the conforming type is a class, the member type may also be defined in a superclass.
\item Via a \textbf{generic parameter} having the same name as the associated type. If the conforming type is not generic but is nested inside of a generic context, a generic parameter of the innermost generic context can be used.\footnote{The latter being allowed was probably an oversight, but it's the behavior implemented today.}
\item Via \textbf{associated type inference}, where it is implicitly derived from the declaration of a witness to a value requirement. (This is actually an extremely complex topic which warrants an entire chapter in itself.)
\item Via a \textbf{default type witness} on the associated type declaration, which is used if all else fails.
\end{enumerate}
The conformance checker is responsible for resolving type witnesses and ensuring they satisfy the requirements of the protocol's requirement signature, as described earlier in \SecRef{requirement sig}. The problem of checking whether concrete types satisfy generic requirements is covered in \SecRef{checking generic arguments}.

\begin{listing}\captionabove{Different ways of declaring a type witness in a conformance}\label{type witness listing}
\begin{Verbatim}
protocol P {
  associatedtype T = Int
  func f(_: T)
}

extension P {
  func f(_: T) {}
}

// Four conforming types:

struct WithMemberType: P {
  struct T {}
}

struct WithGenericParam<T>: P {
  // synthesized: typealias T = T
}

struct WithInferredType: P {
  // synthesized: typealias T = String
  func f(_: String) {}
}

struct WithDefault: P {
  // synthesized: typealias T = Int
}
\end{Verbatim}
\end{listing}

\index{synthesized declaration}
\begin{example}
\ListingRef{type witness listing} illustrates all four possibilities. In \texttt{WithMemberType}, the type witness is the nested struct type named \texttt{T}. In the three remaining cases, the conformance checker actually synthesizes a type alias named \texttt{T} as a member of the conforming type.

In the case of \texttt{WithGenericParam}, the type alias type \texttt{T} has as its underlying type the generic parameter, also named \texttt{T}. Thus it might seem that the generic parameter \texttt{T} is a member type of \texttt{WithGenericParam<T>}:
\begin{Verbatim}
func squared(_ x: WithGenericParam<Int>.T) -> Int {
  return x * x
}
\end{Verbatim}

However, the member type \texttt{T} does not refer to the generic parameter declaration itself, but to the synthesized type alias declaration. If \texttt{WithGenericParam} did not declare a conformance to \texttt{P}, there would be no member type named \texttt{T}, and the type representation \texttt{WithGenericParam<Int>.T} would diagnose an error. Type resolution of member types is discussed in detail in \SecRef{member type repr}.
\end{example}

\paragraph{Projection.}
\index{type witness}%
\index{associated type declaration}%
Given a conformance and an associated type of the conformed protocol, we can ask the conformance for the corresponding type witness. The next section will explain how type substitution of dependent member types uses the type witnesses of a conformance, but first we need to develop the ``algebra'' of type witnesses.

We denote a type witness projection by $\AssocType{[P]A}$, where \texttt{A} is some associated type declared in a protocol \texttt{P}. (Of course, $\pi$ here has nothing to do with the circle constant $\oldstylenums{3.1415926}\ldots\,$; rather, it means ``projection'', or perhaps ``protocol.'')

A type witness projection $\AssocType{[P]A}$ can be applied to a conformance, as long as the conformance is to the same protocol \texttt{P}; so if \texttt{W} is the type witness (where ``\texttt{W}'' is understood as a placeholder for an arbitrary interface type, and not literally a referenced to some type declaration named ``\texttt{W}''), we define:
\[\AssocType{[P]A}\otimes\TP:=\texttt{W}\]

The type witnesses of a normal conformance are interface types which may contain type parameters from the generic signature of the conforming context. In other words, if $\NormalConf\in\ConfObj{G}$, then $\AssocType{[P]A}\otimes\NormalConf\in\TypeObj{G}$.

In \ListingRef{type witness listing}, we have the following:
\begin{gather*}
\AssocType{[P]T}\otimes\ConfReq{WithMemberType}{P}=\texttt{WithMemberType.T}\\
\AssocType{[P]T}\otimes\ConfReq{WithGenericParam}{P}=\ttgp{0}{0}\\
\AssocType{[P]T}\otimes\ConfReq{WithInferredType}{P}=\texttt{String}\\
\AssocType{[P]T}\otimes\ConfReq{WithDefault}{P}=\texttt{Int}
\end{gather*}

The type witnesses of a specialized conformance are completely determined by the underlying normal conformance and conformance substitution map. Once again, only one possible definition leads to a self-consistent algebra. If $\TP = \NormalConf\otimes\Sigma$:
\[
\AssocType{[P]A} \otimes \TP = \AssocType{[P]A} \otimes \bigl(\NormalConf\otimes\Sigma\bigr) = \bigl(\AssocType{[P]A} \otimes\NormalConf\bigr)\otimes\Sigma
\]
Thus, if $\texttt{T}=\texttt{T}_d\otimes\Sigma$ and $\AssocType{[P]A}\otimes\NormalConf=\texttt{W}$, then $\AssocType{[P]A}\otimes\TP=\texttt{W}\otimes\Sigma$. Also, note that if $\Sigma\in\SubMapObj{G}{G^\prime}$, then $\AssocType{[P]A} \otimes \TP\in\TypeObj{G^\prime}$. So the type witnesses of a normal or specialized conformance are understood in relation to the \index{output generic signature}output generic signature of the conformance, just as the replacement types of a substitution map contain type parameters for the output generic signature of the substitution map.

We now study the relationship between global conformance lookup and type witness projection. Consider the ``general type witness expression'':
\[\AssocType{[P]A}\otimes\pP\otimes\texttt{T}_d\otimes\Sigma\]
There are three ways to place parentheses in this expression, and the key property is that the three different evaluation orders produce the same result:
\begin{enumerate}
\item We can look up the conformance of $\texttt{T}_d$ to \texttt{P} to get the normal conformance $\NormalConf$, project the type witness $\AssocType{[P]A}$ to get \texttt{W}, and apply $\Sigma$ to get $\texttt{W}\otimes\Sigma$.
\item We can look up the conformance of $\texttt{T}_d$ to \texttt{P} to get the normal conformance $\NormalConf$, apply $\Sigma$ to get the specialized conformance $\TP$, and project the type witness $\AssocType{[P]A}$ to get $\texttt{W}\otimes\Sigma$.
\item We can apply $\Sigma$ to $\texttt{T}_d$ to get \texttt{T}, look up the conformance of \texttt{T} to \texttt{P} to get the specialized conformance $\TP$, and project the type witness $\AssocType{[P]A}$ to get $\texttt{W}\otimes\Sigma$.
\end{enumerate}
\FigRef{type witness diagram} exhibits the above in the form of a \index{commutative diagram}commutative diagram; the three paths from $\texttt{T}_d$ to $\texttt{W}\otimes\Sigma$ correspond to the three possible evaluations above.

\begin{figure}\captionabove{Type witnesses of normal and specialized conformances}\label{type witness diagram}
\begin{center}
\begin{tikzcd}[column sep=3cm,row sep=1cm]
\texttt{T}_d \arrow[d, "\pP"{left}] \arrow[r, "\Sigma"] &\texttt{T} \arrow[d, "\pP"] \\
\NormalConf \arrow[r, "\Sigma"] \arrow[d, "\AssocType{[P]A}"{left}]&\TP \arrow[d, "\AssocType{[P]A}"]\\
\texttt{W} \arrow[r, "\Sigma"]&\texttt{W}\otimes\Sigma
\end{tikzcd}
\end{center}
\end{figure}

\begin{example}
To make this concrete, say we look up the conformance of \texttt{Array<Int>} to \texttt{Sequence}, and then get the type witness for the \texttt{Element} associated type. The declared interface type of \texttt{Array} is \texttt{Array<\ttgp{0}{0}>}, and the type witness of the \texttt{Element} associated type in $\ConfReq{Array<\ttgp{0}{0}>}{Sequence}$ is the \ttgp{0}{0} generic parameter type.

Our specialized type is \texttt{Array<Int>} with context substitution map $\SubstMap{\SubstType{\ttgp{0}{0}}{Int}}$, so the type witness for \texttt{Element} in $\ConfReq{Array<Int>}{Sequence}$ is $\ttgp{0}{0}\otimes\SubstMap{\SubstType{\ttgp{0}{0}}{Int}}$, which is \texttt{Int}. \FigRef{type witness diagram example} shows the commutative diagram for this case. We can start at the top left and always end up at the bottom right, independent of which of the three paths we take.
\begin{figure}\captionabove{Type witnesses of the conformances of \texttt{Array<\ttgp{0}{0}>} and \texttt{Array<Int>} to \texttt{Sequence}}\label{type witness diagram example}
\begin{center}
\begin{tikzcd}[column sep=2.5cm,row sep=1cm]
\texttt{Array<\ttgp{0}{0}>} \arrow[d, "\protosym{Sequence}"{left}] \arrow[r, "\SubstMap{\SubstType{\ttgp{0}{0}}{Int}}"] &\texttt{Array<Int>} \arrow[d, "\protosym{Sequence}"] \\
\ConfReq{Array<\ttgp{0}{0}>}{Sequence} \arrow[r, "\SubstMap{\SubstType{\ttgp{0}{0}}{Int}}"] \arrow[d, "\AssocType{[Sequence]Element}"{left}]&\ConfReq{Array<Int>}{Sequence} \arrow[d, "\AssocType{[Sequence]Element}"]\\
\texttt{\ttgp{0}{0}} \arrow[r, "\SubstMap{\SubstType{\ttgp{0}{0}}{Int}}"]&\texttt{Int}
\end{tikzcd}
\end{center}
\end{figure}
\end{example}

If we take \IndexSetDefinition{assoctype}{\AssocTypeObj{P}}$\AssocTypeObj{P}$ to mean the set of all associated type declarations of \texttt{P}, and $\ConfPObj{P}{G}$ as the subset of $\ConfObj{G}$ containing only conformances to \texttt{P}, then type witness projection is the following new ``overload'' of the \index{$\otimes$}$\otimes$ operation:
\[\AssocTypeObj{P}\otimes\ConfPObj{P}{G}\longrightarrow\TypeObj{G}\]

\section{Abstract Conformances}\label{abstract conformances}

An \IndexDefinition{abstract conformance}\emph{abstract conformance} represents the conformance of a \index{type parameter}type parameter of some \index{generic signature}generic signature to a protocol. Unlike concrete conformances, abstract conformances do not refer to a specific declaration, nor do they store their type witnesses directly. They are to concrete conformances, what type parameters are to concrete types. If it is understood that \texttt{T} is a type parameter, we use the same notation for abstract conformances as for concrete conformances:
\[\pP\otimes\texttt{T} = \TP\]

If the conformance \emph{requirement} $\TP$ can be \index{derived requirement}derived in a generic signature $G$, then there is an abstract conformance $\TP\in\ConfObj{G}$. (To put it another way, an abstract conformance $\TP$ exists if the \IndexQuery{requiresProtocol}$\Query{requiresProtocol}{G,\,\texttt{T},\,\texttt{P}}$ is true.)

To complete our type substitution algebra, we now define what it means to project a type witness from, or apply a substitution map to, an abstract conformance. Recall that a \index{bound dependent member type}\index{dependent member type}bound dependent member type \texttt{T.[P]A} is a valid type parameter if it can be derived by applying the \IndexStep{AssocDecl}\textsc{AssocDecl} inference rule to some derived conformance requirement $\TP$:
\begin{gather*}
\AssocDeclStepDef
\end{gather*}
The derived conformance requirement $\TP$ gives us the abstract conformance $\TP$, and its type witness for \texttt{A} must be the dependent member type \texttt{T.[P]A}:
\[\AssocType{[P]A} \otimes \TP = \texttt{T.[P]A}\]

As every valid dependent member type is the type witness of an abstract conformance, we can define the application of a substitution map to a dependent member type by factoring the dependent member type in this manner:
\[\texttt{T.[P]A}\otimes\Sigma=\bigl(\AssocType{[P]A} \otimes \TP\bigr)\otimes\Sigma=\AssocType{[P]A}\otimes\bigl(\TP\otimes\Sigma\bigr)\]

We saw how normal and specialized conformances are substituted in \SecRef{conformance subst}. Now, it appears we need the ability to apply a substitution map to an abstract conformance. This operation is named \IndexDefinition{local conformance lookup}\emph{local conformance lookup} by analogy with \index{global conformance lookup}global conformance lookup. Local conformance lookup is \emph{compatible} with global conformance lookup, in this sense: a local conformance lookup with some \index{substitution map}substitution map $\Sigma$, type parameter \texttt{T} and protocol \texttt{P} must return the same conformance as performing a global conformance lookup of $\texttt{T}\otimes\Sigma$ to $\texttt{P}$. This can be expressed as an equation:
\[(\pP\otimes\texttt{T})\otimes\Sigma=\pP\otimes(\texttt{T}\otimes\Sigma)\]

Local conformance lookup is not actually implemented in terms of global conformance lookup, though. In the simple case, when the abstract conformance corresponds to an explicit conformance requirement in the substitution map's input generic signature,  local conformance lookup returns one of the conformances stored by the substitution map. In the general case, local conformance lookup derives the conformance via a \index{conformance path}\emph{conformance path}. This will be revealed in \ChapRef{conformance paths}.

\begin{listing}\captionabove{Applying a substitution map to a dependent member type}\label{dmt subst map listing}
\begin{Verbatim}
struct Concatenation<Elements: Sequence>
    where Elements.Element: Sequence {
  typealias InnerIterator = Elements.Element.Iterator
}

// What is the type of `iter'?
let iter: Concatenation<Array<Array<Int>>.InnerIterator = ...
\end{Verbatim}
\end{listing}
\begin{example}
\ListingRef{dmt subst map listing} shows an example of dependent member type substitution. We're going to work through how the compiler derives the type of the \texttt{iter} variable.
The type annotation references the \texttt{InnerIterator} member type alias with a base type of \texttt{Concatenation<Array<Array<Int>>}, so we need to apply the context substitution map of this base type to the underlying type of the type alias declaration.

The generic signature of \texttt{Concatenation} is the following:
\begin{quote}
\begin{verbatim}
<Elements where Elements: Sequence,
                Elements.[Sequence]Element: Sequence>
\end{verbatim}
\end{quote}
The context substitution map of \texttt{Concatenation<Array<Array<Int>>} is a substitution map for the above input generic signature:
\[
\SubstMapLongC{
\SubstType{Elements}{Array<Array<Int>>}
}{
\SubstConf{Elements}{Array<Array<Int>>}{Sequence}\\
\SubstConf{Elements.Element}{Array<Int>}{Sequence}
}
\]
The underlying type of the \texttt{InnerIterator} type alias is the bound dependent member type \verb|Elements.[Sequence]Element.[Sequence]Iterator|. The compiler applies our substitution map to this dependent member type in three steps:
\begin{enumerate}
\item The base type of the dependent member type is \verb|Elements.[Sequence]Element|, and the associated type \texttt{Iterator} is defined in the \texttt{Sequence} protocol. Therefore there is an abstract conformance
\[\ConfReq{Elements.[Sequence]Element}{Sequence}\]
\item Applying the substitution map to this abstract conformance performs a local conformance lookup into the substitution map. The conforming type and protocol of the abstract conformance is exactly equal to the second conformance requirement in the generic signature, so the local conformance lookup returns the conformance $\ConfReq{Array<Array<Int>>}{Sequence}$.
\item The final step projects the type witness for \texttt{Iterator} from this conformance. This is a specialized conformance, with the conformance substitution map:
\[\SubstMap{\SubstType{\ttgp{0}{0}}{Array<Int>}}\]
In the normal conformance, \texttt{Iterator} is \texttt{IndexingIterator<Array<\ttgp{0}{0}>>}, so:
\begin{gather*}
\AssocType{[Sequence]Iterator}\otimes \ConfReq{Array<Array<Int>>}{Sequence}\\
\qquad {} = \texttt{IndexingIterator<Array<\ttgp{0}{0}>>}\otimes \SubstMap{\SubstType{\ttgp{0}{0}}{Array<Int>}}\\
\qquad {} = \texttt{IndexingIterator<Array<Array<Int>>>}
\end{gather*}
\end{enumerate}
So our final substituted type is \verb|IndexingIterator<Array<Array<Int>>>|.
\end{example}
\begin{example}
An attentive reader might remember from \SecRef{buildingsubmaps} that the construction of the context substitution map of a specialized type is a little tricky, because we have to recursively compute the substituted subject type of each conformance requirement in the generic signature and then perform a global conformance lookup. In the previous example, the generic signature of \texttt{Concatenation} has two conformance requirements, and their original and substituted subject types are as follows:
\begin{gather*}
\texttt{Elements} \Rightarrow \texttt{Array<Array<Int>>}\\
\texttt{Elements.[Sequence]Element} \Rightarrow \texttt{Array<Int>}
\end{gather*}
The computation of each substituted subject type can be understood as applying the \emph{partially-constructed} context substitution map that has been built so far to each original subject type. For the first subject type, the substitution projects the replacement type of the \texttt{Elements} generic parameter:
\[
\texttt{Elements} \otimes \SubstMapLongC{
\SubstType{Elements}{Array<Array<Int>>}
}{
\text{---}\\
\text{---}
} = \texttt{Array<Array<Int>>}
\]
The second time around, the original subject type is itself a dependent member type, so type substitution recursively performs the same dance with a local conformance lookup and type witness projection:
\begin{gather*}
\texttt{Elements.[Sequence]Element} \\
{} \otimes \SubstMapLongC{
\SubstType{Elements}{Array<Array<Int>>}
}{
\SubstConf{Elements}{Array<Array<Int>>}{Sequence}\\
\text{---}
}\\
= \texttt{Array<Int>}
\end{gather*}
\end{example}

\paragraph{Protocol substitution maps.} If \texttt{T} is any interface type (not just a type parameter) conforming to some protocol \texttt{P}, the normal, specialized or abstract conformance $\TP$ defines a substitution map for the protocol generic signature \verb|<Self where Self: P>| in a natural way. This is the \IndexDefinition{protocol substitution map}\emph{protocol substitution map}, denoted by $\Sigma_{\TP}$:
\[\Sigma_{\TP} := \SubstMapC{
\SubstType{Self}{T}
}{
\SubstConf{Self}{T}{P}
}\]
Suppose that our protocol \texttt{P} declares an associated type \texttt{A}. Note that \texttt{Self.[P]A} is the declared interface type of the \index{associated type declaration}associated type \texttt{A}, and $\texttt{Self.[P]A}=\AssocType{[P]A}\otimes\ConfReq{Self}{P}$. Then applying the protocol substitution map to this dependent member type gives the same result as projecting the type witness from the conformance:
\[\texttt{Self.[P]A}\otimes\Sigma_{\TP}=\AssocType{[P]A}\otimes\bigl(\ConfReq{Self}{P}\otimes\Sigma\bigr)=\AssocType{[P]A}\otimes\TP\]

\section{Associated Conformances}\label{associated conformances}
The \index{conformance requirement}conformance requirements stated in a protocol's \index{requirement signature}requirement signature are known as \index{request}\IndexDefinition{associated conformance requirement}\emph{associated conformance requirements} and the concrete conformance corresponding to one is an \IndexDefinition{associated conformance}\emph{associated conformance}. There is an interesting duality between \index{substitution map}substitution maps and conformances:
\begin{center}
\begin{tabular}{rcl}
\toprule
\textbf{Generic signatures:}&&\textbf{Protocols:}\\
\midrule
Generic parameter&$\Leftrightarrow$&Associated type\\
Requirement in signature&$\Leftrightarrow$&Associated requirement\\
\midrule
\textbf{Substitution maps:}&&\textbf{Conformances:}\\
\midrule
Replacement type&$\Leftrightarrow$&Type witness\\
Replacement conformance&$\Leftrightarrow$&Associated conformance\\
\bottomrule
\end{tabular}
\end{center}
Generic signatures and requirement signatures are similar except that the former constrains generic parameters, while the latter constrains associated types. A substitution map records a replacement type for each generic parameter and a replacement conformance for each conformance requirement. A normal conformance records a type witness for each associated type and an associated conformance for each associated conformance requirement.

Recall from \SecRef{requirement sig} that the printed representation of a requirement signature looks like a generic signature with a single \tSelf\ generic parameter. For example, here is the abridged requirement signature of the standard library's \texttt{Collection} protocol:
\begin{quote}
\texttt{<Self where \ttbox{Self:\ Sequence}, \ttbox{Self.Index:\ Comparable}, ...>}
\end{quote}
The special case of an associated conformance requirement with a subject type of \tSelf\ represents a \index{inherited protocol}protocol inheritance relationship, as you already saw in \SecRef{requirement sig}. Other associated conformance requirements constrain the protocol's associated types.

The associated conformances of a normal conformance are populated lazily by the \IndexDefinition{associated conformance request}\Request{associated conformance request}. The request computes the substituted subject type of an associated conformance requirement by applying the \index{protocol substitution map}protocol substitution map for the conformance, and then performs a global conformance lookup with this subject type. This is the same idea as when we do conformance lookups to populate a substitution map (\SecRef{buildingsubmaps}).

The substituted subject type is obtained by applying the protocol substitution map to the subject type of each associated conformance requirement. For example, in the conformance of \texttt{Array<\ttgp{0}{0}>} to \texttt{Collection}, the substituted subject type of the requirement $\ConfReq{Self}{Sequence}$ is just the conforming type:
\[
\tSelf\ \otimes \Sigma_{\ConfReq{Array<\ttgp{0}{0}>}{Collection}} = \texttt{Array<\ttgp{0}{0}>}
\]
The substituted subject type of \verb|Self.Index| is the type witness for \verb|Index|, which is \verb|Int|:
\begin{gather*}
\texttt{Self.Index} \otimes \Sigma_{\ConfReq{Array<\ttgp{0}{0}>}{Collection}}\\
\qquad {} = \AssocType{[Collection]Index} \otimes \ConfReq{Array<\ttgp{0}{0}>}{Collection}\\
\qquad {} = \texttt{Int}
\end{gather*}
With the substituted subject types on hand, the conformance checker then performs a global conformance lookup to find each associated conformance:
\begin{gather*}
\protosym{Sequence} \otimes \texttt{Array<\ttgp{0}{0}>} = \ConfReq{Array<\ttgp{0}{0}>}{Sequence}\\
\protosym{Comparable} \otimes \texttt{Int} = \ConfReq{Int}{Comparable}
\end{gather*}
\paragraph{Notation.} In the type substitution algebra, we will write an associated conformance requirement as $\AssocConf{Self.Index}{Comparable}$. Associated conformance requirements are quite different from abstract conformances, which use the notation $\TP$. An abstract conformance states that a type parameter is known to conform to a protocol in some \emph{generic} signature (possibly as a non-trivial consequence of other requirements), whereas an associated conformance requirement is a \emph{specific} requirement directly appearing in a protocol's \emph{requirement} signature.

\paragraph{Projection.}
Projecting an associated conformance from a normal conformance can be understood as the action of an associated conformance requirement (from a protocol's requirement signature) on the left of a normal conformance (to this protocol):
\[\AssocConf{Self.U}{Q} \otimes \NormalConf\]

With a specialized conformance, we do the same thing as when getting a type witness; first, we get the associated conformance from the underlying normal conformance, and then we apply the conformance substitution map:
\begin{gather*}
\AssocConf{Self.U}{Q}\otimes\TP\\
\qquad {} = \AssocConf{Self.U}{Q}\otimes\bigl(\NormalConf\otimes\Sigma\bigr)\\
\qquad {} = \bigl(\AssocConf{Self.U}{Q}\otimes\NormalConf\bigr)\otimes\Sigma
\end{gather*}
Now we can project associated conformances from normal conformances and specialized conformances. Last but not least, we need to define associated conformance projection from an abstract conformance. Just as the type witnesses of an abstract conformance are dependent member types, associated conformances of abstract conformances are other abstract conformances. In \SecRef{conformance paths exist}, we will show that \emph{all} abstract conformances can be defined this way:
\[
\AssocConf{Self.U}{Q} \otimes \TP = \ConfReq{T.U}{Q}
\]

If we define \IndexSetDefinition{assocconf}{\AssocConfObj{P}}$\AssocConfObj{P}$ as the set of all associated conformance requirements in a protocol \texttt{P}, then we get a new ``overload'' of the \index{$\otimes$}$\otimes$ \index{binary operation}binary operation:
\[\AssocConfObj{P}\otimes\ConfPObj{P}{G}\longrightarrow\ConfObj{G}\]
One more overload of $\otimes$ is described in \SecRef{checking generic arguments}. A complete summary of the type substitution algebra appears in \AppendixRef{notation summary}.

\begin{listing}\caption{Different kinds of associated conformances}\label{associated conformance example}
\begin{Verbatim}
protocol P {
  associatedtype A: Equatable
  associatedtype B: Equatable
  associatedtype C: Equatable
}

struct S<T: Equatable>: P {
  typealias A = Int
  typealias B = Array<Int>
  typealias C = T
}
\end{Verbatim}
\end{listing}

\begin{example}
The associated conformances of a normal conformance can themselves be any kind of conformance, including normal, specialized or abstract. \ListingRef{associated conformance example} shows these possibilities. The protocol \texttt{P} states three associated conformance requirements, and each of the associated conformances of the normal conformance \verb|S<T>: P| are a different kind of conformance:
\begin{quote}
\begin{tabular}{lll}
\toprule
\textbf{Requirement}&\textbf{Associated conformance}&\textbf{Kind}\\
\midrule
$\AssocConf{A}{Equatable}$&$\ConfReq{Int}{Equatable}$&Normal\\
$\AssocConf{B}{Equatable}$&$\ConfReq{Array<Int>}{Equatable}$&Specialized\\
$\AssocConf{C}{Equatable}$&$\ConfReq{T}{Equatable}$&Abstract\\
\bottomrule
\end{tabular}
\end{quote}
The case where the associated conformance is abstract is important, because it arises when the type witness is a type parameter of the conforming type's generic signature.

Now, let $\Sigma:=\SubstMapC{\SubstType{\ttgp{0}{0}}{String}}{\SubstConf{\ttgp{0}{0}}{String}{Equatable}}$.
Consider what happens when we apply the projection $\AssocConf{Self.C}{Equatable}$ to the specialized conformance $\ConfReq{S<String>}{P}=\ConfReq{S<\ttgp{0}{0}>}{P}\otimes\Sigma$:
\begin{gather*}
\AssocConf{Self.[P]C}{Equatable} \otimes \ConfReq{S<String>}{P}\\
\qquad {} = \bigl(\AssocConf{Self.[P]C}{Equatable} \otimes\ConfReq{S<\ttgp{0}{0}>}{P}\bigr)\otimes\Sigma\\
\qquad {} = \ConfReq{\ttgp{0}{0}}{Equatable} \otimes\Sigma
\end{gather*}
The associated conformance projection operation actually turns around and reduces to a local conformance lookup into the substitution map, which gives us the final result:
\[\ConfReq{\ttgp{0}{0}}{Equatable} \otimes \Sigma = \ConfReq{String}{Equatable}\]
This has some unexpected consequences, which are explored in \SecRef{recursive conformances}.
\end{example}

\section{Source Code Reference}\label{conformancesourceref}

\subsection*{Global Conformance Lookup}

Key source files:
\begin{itemize}
\item \SourceFile{include/swift/AST/ConformanceLookup.h}
\item \SourceFile{lib/AST/ConformanceLookupTable.h}
\item \SourceFile{lib/AST/ConformanceLookup.cpp}
\item \SourceFile{lib/AST/ConformanceLookupTable.cpp}
\end{itemize}
Other source files:
\begin{itemize}
\item \SourceFile{include/swift/AST/DeclContext.h}
\end{itemize}

\IndexSource{global conformance lookup}
\apiref{lookupConformance()}{function}
Performs global conformance lookup of a type to a protocol. Does not check conditional requirements. To check conditional requirements, use \texttt{checkConformance()} described in \SecRef{extensionssourceref}.

\IndexSource{conformance lookup table}
\apiref{ConformanceLookupTable}{class}
A conformance lookup table for a nominal type. Every \texttt{NominalTypeDecl} has a private instance of this class, but it is not exposed outside of the global conformance lookup implementation.

\IndexSource{local conformance}
\apiref{IterableDeclContext}{class}
Base class inherited by \texttt{NominalTypeDecl} and \texttt{ExtensionDecl}.
\begin{itemize}
\item \texttt{getLocalConformances()} returns a list of conformances directly declared on this nominal type or extension.
\end{itemize}

\index{nominal type declaration}
\apiref{NominalTypeDecl}{class}
See also \SecRef{declarationssourceref}.
\begin{itemize}
\item \texttt{getAllConformances()} returns a list of all conformances declared on this nominal type, its extensions, and inherited from its superclass, if any.
\end{itemize}

\subsection*{Operations on Conformances}

Key source files:
\begin{itemize}
\item \SourceFile{include/swift/AST/ProtocolConformanceRef.h}
\item \SourceFile{include/swift/AST/ProtocolConformance.h}
\item \SourceFile{lib/AST/ProtocolConformanceRef.cpp}
\item \SourceFile{lib/AST/ProtocolConformance.cpp}
\end{itemize}

\IndexSource{conformance}
\IndexSource{abstract conformance}
\apiref{ProtocolConformanceRef}{class}
A protocol conformance. Stores a single pointer, and is cheap to pass around by value.
\begin{itemize}
\item \texttt{isInvalid()} answers if this is an invalid conformance reference, meaning the type did not actually conform to the protocol.
\item \texttt{isAbstract()} answers if this is an abstract conformance reference.
\item \texttt{isConcrete()} answers if this is a concrete conformance reference.
\item \texttt{getConcrete()} returns the \texttt{ProtocolConformance} instance if this is a concrete conformance.
\item \texttt{getRequirement()} returns the \texttt{ProtocolDecl} instance if this is an abstract or concrete conformance.
\item \texttt{subst()} returns the protocol conformance obtained by applying a substitution map to this conformance.
\end{itemize}

\IndexSource{concrete conformance}
\apiref{ProtocolConformance}{class}
A concrete protocol conformance. This class is the root of a class hierarchy shown in \FigRef{conformancehierarchy}. Concrete protocol conformances are allocated in the AST context, and are always passed by pointer. See \SecRef{extensionssourceref} for documentation about conditional conformance.

\begin{figure}\captionabove{The \texttt{ProtocolConformance} class hierarchy}\label{conformancehierarchy}
\begin{center}
\begin{tikzpicture}[%
  grow via three points={one child at (0.5,-0.7) and
  two children at (0.5,-0.7) and (0.5,-1.4)},
  edge from parent path={[->] (\tikzparentnode.south) |- (\tikzchildnode.west)}]
  \node [class] {\texttt{\vphantom{p}ProtocolConformance}}
    child { node [class] {\texttt{\vphantom{p}RootProtocolConformance}}
      child { node [class] {\texttt{\vphantom{p}NormalProtocolConformance}}}
      child { node [class] {\texttt{\vphantom{p}SelfProtocolConformance}}}
    }
    child [missing] {}
    child [missing] {}
    child { node [class] {\texttt{\vphantom{p}InheritedProtocolConformance}}}
    child { node [class] {\texttt{\vphantom{p}SpecializedProtocolConformance}}};
\end{tikzpicture}
\end{center}
\end{figure}

\begin{itemize}
\item \texttt{getType()} returns the \IndexSource{conforming type}conforming type.
\item \texttt{getProtocol()} returns the conformed protocol.
\item \texttt{getTypeWitness()} returns the \IndexSource{type witness}type witness for an associated type.
\item \texttt{getAssociatedConformance()} returns the \IndexSource{associated conformance}associated conformance for a conformance requirement in the protocol's requirement signature.
\item \texttt{subst()} returns the protocol conformance obtained by applying a substitution map to this conformance.
\end{itemize}

\apiref{RootProtocolConformance}{class}
Abstract base class for \texttt{NormalProtocolConformance} and \texttt{SelfProtocolConformance}. Inherits from \texttt{ProtocolConformance}.

\IndexSource{normal conformance}
\apiref{NormalProtocolConformance}{class}
A normal protocol conformance. Inherits from \texttt{RootProtocolConformance}.
\begin{itemize}
\item \texttt{getDeclContext()} returns the conforming declaration context, either a nominal type declaration or extension.
\item \texttt{getGenericSignature()} returns the generic signature of the conforming context.
\end{itemize}

\IndexSource{conformance substitution map}
\IndexSource{specialized conformance}
\apiref{SpecializedProtocolConformance}{class}
A specialized protocol conformance. Inherits from \texttt{ProtocolConformance}.
\begin{itemize}
\item \texttt{getGenericConformance()} returns the underlying normal conformance.
\item \texttt{getSubstitutionMap()} returns the conformance substitution map.
\end{itemize}

\subsection*{Lazy Loading}

The interface between conformances and the module system is mediated by an abstract base classes defined in the below header file:
\begin{itemize}
\item \SourceFile{include/swift/AST/LazyResolver.h}
\end{itemize}

\apiref{LazyConformanceLoader}{class}
Abstract base class implemented by different kinds of modules to fill out conformances. For \index{serialized module}serialized modules, this populates the mapping from requirements to witnesses by deserializing records. For \index{imported module}imported modules, this populates the mapping by inspecting \index{Clang}Clang declarations.

\apiref{AssociatedConformanceRequest}{class}
Request evaluator request for lazily looking up an \IndexSource{associated conformance request}associated conformance of a normal conformance that was parsed from source. Computes the substituted subject type of the requirement and calls global conformance lookup.
\end{document}
