Generics

Without generics, swapping two Int values and swapping two String values require two separate functions with identical bodies — the logic has nothing to do with Int or String specifically, only the shape of "two values of the same type" matters. Generic code names that shape once with a placeholder type and lets the compiler generate (or dynamically witness) the concrete version for every type actually used, with the same compile-time type checking a non-generic function gets.

A generic function declares one or more type parameters in angle brackets right after its name (<T> above); each type parameter stands in for a real type that isn’t known until the function is called, and every use of that parameter within the function’s signature and body must agree with each other (both a and b are T, so swapValues can never be called with an Int and a String). A generic type — a struct, class, or enumeration — declares its type parameters the same way right after its name; each concrete type used at the point of instantiation (Stack<Int>, Stack<String>) produces its own independent version of the type, sharing one implementation but never mixing their stored data.

A type parameter’s name is arbitrary, but convention favors a single uppercase letter (T, U, V) when the parameter is a placeholder with no more specific meaning, and a descriptive UpperCamelCase name (Element, Key, Value, RawValue) when it plays a specific, well-known role — exactly as the standard library names Array’s `Element and Dictionary’s `Key/Value. Extending a generic type never repeats its type-parameter list (extension Stack { }, not extension Stack<Element> { }); the original parameter names are already in scope for every member the extension adds, and the extension itself can attach a further constraint with where that only some instantiations of the type satisfy.

An unconstrained type parameter (plain <T>) supports only operations every type supports — assignment, passing around — since the compiler cannot assume anything else about it. A type constraint, written <T: SomeProtocol> or <T: SomeClass>, requires every type substituted for T to conform to that protocol (or inherit from that class), which is what lets findIndex use == (an Equatable requirement) in its body at all — exactly the same constraint syntax used on an associated type, covered next.

An associatedtype gives a protocol its own generic-like placeholder: a conforming type supplies the actual type (often inferred automatically, as Stack’s `Item is inferred to be Element above) rather than the caller choosing it as with a generic parameter. An associated type can carry its own constraint (Item: Equatable), and a where clause after a function’s parameter list can further constrain how two generic types' associated types relate to each other — C1.Item == C2.Item is a same-type requirement, satisfiable only when both containers hold the same kind of item.

A where clause can appear in several positions, each restricting something different: after a generic function’s or type’s parameter list (constraining the type parameters themselves), on an extension (restricting which instantiations of a generic type the extension’s members apply to), on an associatedtype declaration (constraining the associated type in terms of the protocol’s own Self or other associated types), and contextually on a for-in loop or other pattern-matching construct, where it acts as an extra filter rather than a generic constraint at all (see Control Flow and Pattern Matching for that second, unrelated use of the same keyword).

A subscript can declare its own type parameters in angle brackets after subscript, independent of (and, on a generic type, in addition to) the enclosing type’s own parameters, with a where clause allowed in the same position a generic function’s would be — the plain, non-generic subscript syntax itself is covered in Methods and Subscripts.

Every generic type parameter implicitly requires Copyable (and Escapable) unless told otherwise, exactly like an ordinary type declaration (see Structures and Classes for ~Copyable types themselves) — which is why duplicate above can freely return two copies of T with no constraint written at all. Writing ~Copyable in a type parameter’s own constraint list, as store does, suppresses that implicit requirement for this one generic context, letting a noncopyable type be substituted for T; the tradeoff is that the generic code itself can then no longer assume it may copy a T value, only move (consuming) or borrow it.

Swift 6.2 extended generic parameter lists beyond types to plain integer literals: InlineArray<3, Int>’s first parameter, `3, is a compile-time integer value baked into the type itself, not a further placeholder type — InlineArray<3, Int> and InlineArray<4, Int> are as distinct as Stack<Int> and Stack<String> are. This is what lets InlineArray store its elements inline with a size fixed at compile time and no heap allocation at all; see Collections for InlineArray and Span in full.

Writing some P directly on a parameter’s type is shorthand for an ordinary generic type parameter constrained to P, without naming that parameter at all — sum above is exactly equivalent to genericSum, just without the <S: Sequence<Int>> list, and both are still true generics: the compiler still generates (or specializes) code per concrete type substituted at the call site, and the caller still fully determines the concrete type, unlike any P. See Opaque and Boxed Protocol Types for some used as a return type (where the two cases — parameter and return position — differ in who chooses the concrete type) and for the full comparison against any.

TSPL: Generics; Generic Parameters and Arguments.