You want a Repository protocol that abstracts over your persistence layer — SwiftData in production, an in-memory stub in tests — but the moment you add an associated type, the protocol refuses to behave like a regular type. You can’t store it in a property, can’t put it in an array, and the compiler greets you with “protocol can only be used as a generic constraint.” Associated types are one of Swift’s most powerful features, and also one of its most misunderstood.

In this post you’ll learn what associated types are, how to constrain them with where clauses, and how to handle the existential restriction through primary associated types (Swift 5.7) and manual type-erased wrappers. We won’t cover every corner of @_typeEraser or ABI-level details — the focus is on patterns you’ll reach for daily.

Contents

• The Problem
• Defining and Satisfying Associated Types
• where Clauses and Refined Constraints
• Advanced Usage
• Performance Considerations
• When to Use (and When Not To)
• Summary

The Problem

You’re building a Pixar film catalogue app and you want a generic repository layer. Films, characters, and studios each need fetch, save, and delete operations, but you don’t want to write three nearly-identical protocols. Your first instinct:

// First attempt — using `any Identifiable` as the model type
protocol FilmRepository {
    func fetch(id: AnyHashable) -> (any Identifiable)?
    func save(_ model: any Identifiable) throws
    func delete(id: AnyHashable) throws
    func fetchAll() -> [any Identifiable]
}

This compiles but immediately shows its weakness: you’ve lost all type information. fetchAll() returns [any Identifiable] — you’d have to cast every element to work with it. The repository’s type-safety guarantee is gone before you’ve written a single conforming type.

The natural next step is to make the model type a parameter of the protocol itself:

// What we want — but how?
protocol Repository {
    // The model type isn't known yet; each conformer will specify it
    associatedtype Model: Identifiable
    func fetch(id: Model.ID) -> Model?
    func save(_ model: Model) throws
    func delete(id: Model.ID) throws
    func fetchAll() -> [Model]
}

// This line no longer compiles:
var repo: Repository  // ❌ "Use of protocol 'Repository' as a type is only allowed
                      //    when the protocol has no associated type requirements"

The error is the compiler’s way of saying: “I can’t represent a bare Repository value because I don’t know what Model is.” To use a protocol with associated types as a type, you must either pin the associated type (via a concrete generic, an opaque type, or a primary associated type constraint) or build a type-erased wrapper.

Defining and Satisfying Associated Types

The associatedtype keyword declares a placeholder type within the protocol. Each conforming type fills in the placeholder via a typealias or — more commonly — through type inference from the method signatures.

protocol Repository {
    associatedtype Model: Identifiable & Hashable

    func fetch(id: Model.ID) -> Model?
    func save(_ model: Model) throws
    func delete(id: Model.ID) throws
    func fetchAll() -> [Model]
}

// PixarFilm satisfies the protocol — Swift infers Model = PixarFilm
// because `save(_ model: PixarFilm)` matches `save(_ model: Model)`
struct PixarFilm: Identifiable, Hashable {
    let id: UUID
    let title: String
    let studio: String
    let releaseYear: Int
}

struct SwiftDataFilmRepository: Repository {
    // No explicit `typealias Model = PixarFilm` needed —
    // the compiler infers it from the method signatures below
    private var modelContext: ModelContext?  // Simplified for clarity

    func fetch(id: UUID) -> PixarFilm? {
        // In a real implementation, query ModelContext
        nil // Simplified for clarity
    }

    func save(_ model: PixarFilm) throws {
        // modelContext?.insert(model)  — Simplified for clarity
    }

    func delete(id: UUID) throws {
        // Simplified for clarity
    }

    func fetchAll() -> [PixarFilm] {
        [] // Simplified for clarity
    }
}

// A lightweight mock for unit tests — same protocol, different Model backing
struct MockFilmRepository: Repository {
    private var storage: [UUID: PixarFilm] = [:]

    func fetch(id: UUID) -> PixarFilm? { storage[id] }

    mutating func save(_ model: PixarFilm) throws {
        storage[model.id] = model
    }

    mutating func delete(id: UUID) throws {
        storage.removeValue(forKey: id)
    }

    func fetchAll() -> [PixarFilm] { Array(storage.values) }
}

The protocol defines the contract; each conformer supplies the concrete Model type. The compiler verifies every conformance at compile time — there’s no runtime surprise about what Model actually is.

Explicit typealias When Inference Is Ambiguous

Swift usually infers the associated type from the method signatures. Occasionally inference is ambiguous — for example, if a conformer has multiple methods that could each satisfy the requirement differently. In those cases, be explicit:

struct CharacterRepository: Repository {
    typealias Model = PixarCharacter  // Explicit — removes ambiguity

    func fetch(id: UUID) -> PixarCharacter? { nil }
    func save(_ model: PixarCharacter) throws { }
    func delete(id: UUID) throws { }
    func fetchAll() -> [PixarCharacter] { [] }
}

struct PixarCharacter: Identifiable, Hashable {
    let id: UUID
    let name: String
    let film: String
}

where Clauses and Refined Constraints

The real power of associated types emerges when you combine them with where clauses to express precise constraints. A where clause can constrain an associated type to conform to additional protocols, equal another type, or satisfy a compound requirement.

// Require that Model's ID is always a UUID — no other ID types allowed
protocol UUIDRepository: Repository where Model.ID == UUID {
    func fetchBatch(ids: Set<UUID>) -> [Model]
}

// Require that repositories whose Model is a PixarFilm also support
// searching by title — only adds the extra requirement when Model == PixarFilm
extension Repository where Model == PixarFilm {
    func search(title: String) -> [PixarFilm] {
        fetchAll().filter { $0.title.localizedCaseInsensitiveContains(title) }
    }
}

// Generic function constrained to repositories whose model is Equatable
func containsDuplicate<R: Repository>(
    in repository: R,
    model: R.Model
) -> Bool where R.Model: Equatable {
    repository.fetchAll().filter { $0 == model }.count > 1
}

where clauses on extensions are especially useful: they let you add behaviour to all conformers that meet a refined constraint without modifying the protocol itself. In the example above, search(title:) is automatically available on any Repository whose Model is PixarFilm — you don’t touch SwiftDataFilmRepository or MockFilmRepository.

Advanced Usage

Primary Associated Types (Swift 5.7+)

SE-0346 introduced primary associated types, which let you constrain an associated type directly in angle brackets — the same syntax used by generic types:

// Declare `Model` as the primary associated type
protocol Repository<Model> {
    associatedtype Model: Identifiable & Hashable
    func fetch(id: Model.ID) -> Model?
    func fetchAll() -> [Model]
    func save(_ model: Model) throws
    func delete(id: Model.ID) throws
}

// Now you can use constrained existentials:
func displayFilms(from repo: any Repository<PixarFilm>) {
    // `Model` is pinned to PixarFilm — safe to call fetchAll()
    let films = repo.fetchAll()
    films.forEach { print($0.title) }
}

// Or opaque types with constrained associated type:
func makeFilmRepository() -> some Repository<PixarFilm> {
    SwiftDataFilmRepository()
}

Primary associated types bridge the gap between the old “PAT can’t be used as existential” rule and the need for type-erased storage. The constraint any Repository<PixarFilm> pins Model to PixarFilm, which satisfies the compiler’s requirement to know the associated type’s identity.

Warning: You can only constrain the primary associated type in angle brackets. Secondary associated types (those not declared in the protocol’s primary list) still require a where clause or a concrete generic.

Manual Type Erasure: AnyRepository

When you need to store a heterogeneous collection of repositories or pass one through an API that can’t use generics, build a type-erased wrapper. This is the pattern behind AnyIterator, AnyPublisher, and AnySequence in the standard library and Combine.

// The type-erased wrapper captures each method as a closure,
// hiding the concrete repository type behind AnyRepository<Model>
struct AnyRepository<Model: Identifiable & Hashable>: Repository {
    // Each protocol requirement is stored as a closure
    private let _fetch: (Model.ID) -> Model?
    private let _fetchAll: () -> [Model]
    private let _save: (Model) throws -> Void
    private let _delete: (Model.ID) throws -> Void

    // The initialiser accepts any Repository whose Model matches
    init<R: Repository>(_ base: R) where R.Model == Model {
        _fetch     = { base.fetch(id: $0) }
        _fetchAll  = { base.fetchAll() }
        _save      = { try base.save($0) }
        _delete    = { try base.delete(id: $0) }
    }

    func fetch(id: Model.ID) -> Model? { _fetch(id) }
    func fetchAll() -> [Model]         { _fetchAll() }
    func save(_ model: Model) throws   { try _save(model) }
    func delete(id: Model.ID) throws   { try _delete(id) }
}

// Usage: store either repository behind the same erased type
let production = AnyRepository(SwiftDataFilmRepository())
let mock       = AnyRepository(MockFilmRepository())

// Both have type AnyRepository<PixarFilm> — storable in a property
var activeRepository: AnyRepository<PixarFilm> = production

// Swap to mock for testing without changing call sites
activeRepository = mock

The closure-capture approach is the canonical manual type erasure pattern. It has a small overhead — one extra indirection per call through the closure — but it’s explicit, debuggable, and doesn’t require @_typeEraser or other compiler-private annotations.

Recursive Associated Type Constraints

where clauses can reference other associated types in the same protocol, enabling recursive or mutually-constrained designs:

protocol Sequel {
    associatedtype Original: Identifiable
    associatedtype This: Identifiable where This.ID == Original.ID
    var original: Original { get }
    var sequel: This { get }
}

Use this sparingly — deep associated type chains quickly become difficult to reason about and hard to satisfy in conforming types.

Performance Considerations

Associated types are a compile-time feature. Unlike existentials (any Protocol), there is no runtime witness-table lookup overhead and no existential box allocation when you use a protocol with an associated type through a concrete generic. The compiler generates a specialised version of every generic function for each concrete type combination — this is called generic specialisation.

The manual AnyRepository wrapper does introduce one extra indirection per method call (the closure call), but this is far cheaper than a full existential box lookup with its associated heap allocation for values larger than 24 bytes.

Usage pattern	Dispatch	Allocation	Inlining
<R: Repository> generic	Static	Stack	Yes
some Repository<PixarFilm>	Static	Stack	Yes
any Repository<PixarFilm>	Dynamic	Heap (if > 24B)	No
AnyRepository<PixarFilm>	Dynamic (closure)	Stack (wrapper struct)	Partial

Apple Docs: associatedtype — The Swift Programming Language — Generics

For dependency injection in non-hot paths (view model initialisation, service locator, test setup), AnyRepository or any Repository<PixarFilm> are both fine choices. For tight loops or rendering code, prefer the concrete generic <R: Repository> form.

When to Use (and When Not To)

Scenario	Recommendation
Protocol must vary over a single type (repository, renderer, parser)	associatedtype — it’s exactly what the feature is designed for
You need to store mixed conformers in a collection	Manual type erasure (AnyRepository) or any Protocol<PrimaryType>
Protocol is used only as a generic constraint	Plain associatedtype — no extra machinery needed
You want to add conditional behaviour for specific Model types	extension Repository where Model == PixarFilm
Associated type creates an existential restriction that’s hard to work around	Consider a concrete generic parameter instead of a protocol with PAT
API is public and Model is always fixed at the call site	Primary associated type syntax — cleanest caller experience

Summary

• associatedtype makes a protocol generic over a type that each conformer supplies — it’s the mechanism that lets Repository, Collection, and Sequence work for any model type.
• Swift infers the associated type from method signatures in most cases; use an explicit typealias when inference is ambiguous.
• where clauses on protocol extensions add requirements to specific associated type combinations, enabling conditional behaviour without touching conforming types.
• Primary associated types (Swift 5.7, SE-0346) allow constrained existentials (any Repository<PixarFilm>) and constrained opaque types (some Repository<PixarFilm>), lifting the old “PAT can only be used as a generic constraint” restriction for pinned types.
• When you need a type-erased wrapper, the closure-capture pattern (AnyRepository) is explicit, performant, and the same approach used by AnyIterator and AnyPublisher in Apple’s own frameworks.

With associated types under your belt, the next step is understanding the advanced generic patterns that build on top of them — including conditional conformance, phantom types, and generic subscripts — covered in Advanced Generics in Swift.

Related Posts (Intermediate)

• some vs any in Swift: Opaque and Existential Types
• Advanced Generics in Swift