Fix typos in Compiling Swift Generics documentation

docs/Generics/generics.tex

@@ -1495,7 +1495,7 @@ \section{Structural Types}
 
 \index{autoclosure function type}
 \index{tuple splat}
-The \texttt{@autoclosure} attribute instructs the type checker to treat the corresponding argument in the caller as if it were a value of type \texttt{T}, rather than a function type \texttt{()~->~T}. The argument is then wrapped inside an implicit closure expression. In the body of the callee, an \texttt{@autoclosure} parameter behaves exactly like an ordinary function value, and can be called to evaluate the expression provided by the caller.
+The \texttt{@autoclosure} attribute instructs the type checker to treat the corresponding argument in the caller as if it was a value of type \texttt{T}, rather than a function type \texttt{()~->~T}. The argument is then wrapped inside an implicit closure expression. In the body of the callee, an \texttt{@autoclosure} parameter behaves exactly like an ordinary function value, and can be called to evaluate the expression provided by the caller.
 
 \medskip
 Note that the following are two different function types:
@@ -1553,7 +1553,7 @@ \section{Structural Types}
 \index{concrete metatype type}
 \index{instance type}
 \paragraph{Metatype types}
-Types are values in Swift, and a metatype is the type of a type used as a value. The metatype of a type \texttt{T} is written as \texttt{T.Type}. The type \texttt{T} is the \emph{instance type} of the metatype. For example \texttt{(()~->~()).Type} is the metatype type with the instance type \verb|() -> ()|. This metatype has one value, the function type \verb|() -> ()|.
+Types are values in Swift, and a metatype is the type of a type used as a value. The metatype of a type \texttt{T} is written as \texttt{T.Type}. The type \texttt{T} is the \emph{instance type} of the metatype. For example, \texttt{(()~->~()).Type} is the metatype type with the instance type \verb|() -> ()|. This metatype has one value, the function type \verb|() -> ()|.
 
 Metatypes are sometimes referred to as \emph{concrete metatypes}, to distinguish them from \emph{existential metatypes}. Most concrete metatypes are singleton types, where the only value is the instance type itself. One exception is class metatypes for non-final classes; the values of a class metatype include the class type itself, but also all subclasses of the class.
 
@@ -1619,7 +1619,7 @@ \section{Abstract Types}
 \paragraph{Parameterized protocol types}
 A parameterized protocol type\footnote{The evolution proposal calls them ``constrained protocol types''; here we're going to use the terminology that appeared in the compiler implementation itself. Perhaps the latter should be renamed to match the evolution proposal at some point.} stores a protocol type together with a list of generic arguments. As a constraint type, it expands to a conformance requirement together with one or more same-type requirements. The same-type requirements constrain the protocol's \emph{primary associated types}, which are declared with a syntax similar to a generic parameter list.
 
-The written representation looks like a generic nominal type, except the named declaration is a protocol, for example \texttt{Sequence<Int>}. Full details appear in Section~\ref{protocols}. Parameterized protocol types were introduced in Swift 5.7 \cite{se0346}.
+The written representation looks like a generic nominal type, except the named declaration is a protocol, for example, \texttt{Sequence<Int>}. Full details appear in Section~\ref{protocols}. Parameterized protocol types were introduced in Swift 5.7 \cite{se0346}.
 
 \index{existential type}
 \paragraph{Existential types}
@@ -1731,12 +1731,12 @@ \section{Miscellaneous Types}
 let myPets: Array = ["Zelda", "Giblet"]
 \end{Verbatim}
 \index{underlying type}
-One other place where unbound generic types can appear is in the underlying type of a non-generic type alias, which is shorthand for declaring a generic type alias that forwards its generic arguments. For example, the following declarations two are equivalent:
+One other place where unbound generic types can appear is in the underlying type of a non-generic type alias, which is shorthand for declaring a generic type alias that forwards its generic arguments. For example, the following two declarations are equivalent:
 \begin{Verbatim}
 typealias MyDictionary = Dictionary
 typealias MyDictionary<Key, Value> = Dictionary<Key, Value>
 \end{Verbatim}
-Unbound generic types are also occasionally useful in diagnostics when you want to print the name of a type declaration only (like \texttt{Outer.Inner}) without the generic parameters of its declared interface type (\texttt{Outer<T>.Inner<U>} for example).
+Unbound generic types are also occasionally useful in diagnostics when you want to print the name of a type declaration only (like \texttt{Outer.Inner}) without the generic parameters of its declared interface type (\texttt{Outer<T>.Inner<U>}, for example).
 
 \index{type variable type}
 \index{constraint solver arena}
@@ -1893,7 +1893,7 @@ \section{Source Code Reference}\label{typesourceref}
 \begin{Verbatim}
 FunctionType *funcTy = type->castTo<FunctionType>();
 \end{Verbatim}
-These template methods desugar the type if it is a sugared type, and the casted type can never itself be a sugared type. This is usually what you want; for example if \texttt{type} is the \texttt{Swift.Void} type alias type, then \texttt{type->is<TupleType>()} returns true, because it is for all intents and purposes a tuple (an empty tuple), except when printed in diagnostics.
+These template methods desugar the type if it is a sugared type, and the casted type can never itself be a sugared type. This is usually what you want; for example, if \texttt{type} is the \texttt{Swift.Void} type alias type, then \texttt{type->is<TupleType>()} returns true, because it is for all intents and purposes a tuple (an empty tuple), except when printed in diagnostics.
 
 There are also top-level template functions \verb|isa<>|, \verb|dyn_cast<>| and \verb|cast<>| that operate on \texttt{TypeBase *}. Using these with \texttt{Type} is an error; you must explicitly unwrap the pointer with \texttt{getPointer()}. These casts do not desugar, and permit casting to sugared types. This is occasionally useful if you need to handle sugared types differently from canonical types for some reason:
 \begin{Verbatim}
@@ -1938,7 +1938,7 @@ \section{Source Code Reference}\label{typesourceref}
 Type ty = ...;
 visitor.visit(ty);
 \end{Verbatim}
-The \texttt{TypeVisitor} also defines various methods corresponding to abstract base classes in the \texttt{TypeBase} hierarchy, so for example you can override \texttt{visitNominalType()} to handle all nominal types at once.
+The \texttt{TypeVisitor} also defines various methods corresponding to abstract base classes in the \texttt{TypeBase} hierarchy, so, for example, you can override \texttt{visitNominalType()} to handle all nominal types at once.
 
 The \texttt{TypeVisitor} preserves information if it receives a sugared type; for example, visiting \texttt{Int?}\ will call \texttt{visitOptionalType()}, while visiting \texttt{Optional<Int>} will call \texttt{visitBoundGenericEnumType()}. In the common situation where the semantics of your operation do not depend on type sugar, you can use the \texttt{CanTypeVisitor} template class instead. Here, the \texttt{visit()} method takes a \texttt{CanType}, so \texttt{Int?}\ will need to be canonicalized to \texttt{Optional<Int>} before being passed in.
 
@@ -2321,7 +2321,7 @@ \section{Storage Declarations}
 \index{typed pattern}
 \index{tuple pattern}
 \begin{example}
-A funny quirk of the pattern grammar is that typed patterns and tuple patterns do not compose in the way one might think. If ``\texttt{let x:~Int}'' is a typed pattern declaring a variable \texttt{x} type with annotation \texttt{Int}, and ``\texttt{let (x, y)}'' is a tuple pattern declaring two variables \texttt{x} and \texttt{y}, you might expect ``\texttt{let~(x:~Int,~y:~Int)}'' to declare two variables \texttt{x} and \texttt{y} with type annotations \texttt{Int} and \texttt{String} respectively; what actually happens is you get a tuple pattern declaring two variables named \texttt{Int} and \texttt{String} that binds a two-element tuple with \emph{labels} \texttt{x} and \texttt{y}:
+A funny quirk of the pattern grammar is that typed patterns and tuple patterns do not compose in the way one might think. If ``\texttt{let x:~Int}'' is a typed pattern declaring a variable \texttt{x} type with annotation \texttt{Int}, and ``\texttt{let (x, y)}'' is a tuple pattern declaring two variables \texttt{x} and \texttt{y}, you might expect ``\texttt{let~(x:~Int,~y:~String)}'' to declare two variables \texttt{x} and \texttt{y} with type annotations \texttt{Int} and \texttt{String} respectively; what actually happens is you get a tuple pattern declaring two variables named \texttt{Int} and \texttt{String} that binds a two-element tuple with \emph{labels} \texttt{x} and \texttt{y}:
 \begin{Verbatim}
 let (x: Int, y: String) = (x: 123, y: "hello")
 print(Int)  // huh? prints 123