Answer.

Background

Custom generic parameters were introduced in Swift protocols with the keyword associatedtype from the very first release of Swift, providing greater control over type abstraction and behavior.

Problem

If a protocol declares a requirement where a certain type must be defined (e.g., the type of elements in a container) — without associatedtype, using the protocol with abstraction becomes impossible: types must be rigidly fixed, losing the ability to write generic code.

Solution

associatedtype allows the declarative declaration of a related type in a protocol, which is defined by the specific implementation of the protocol. This allows writing protocols and generic functions without knowing specific types at compile time.

Example of a protocol with associatedtype:

protocol MyContainer {
    associatedtype Item
    var count: Int { get }
    mutating func append(_ item: Item)
    subscript(i: Int) -> Item { get }
}

struct IntStack: MyContainer {
    var items = [Int]()
    mutating func append(_ item: Int) { items.append(item) }
    var count: Int { items.count }
    subscript(i: Int) -> Int { items[i] }
    // Swift infers that Item = Int
}

Key features:

Allows creating protocols with type parameterization (closer to template concepts in C++),
Cannot use a protocol with associatedtype "as a type" directly (let x: MyContainer // error),
Suitable for building complex generic collections, algebraic structures, and APIs.

Trick Questions.

Why is associatedtype needed if generics already exist in Swift?

Answer: Generics and associatedtype solve similar but different problems. A generic parameter applies to a type or function, enabling the creation of generic structures and methods. Associatedtype is an abstraction within a protocol, enforcing a requirement for implementing types to define their own type. Use generics for universal algorithms or containers, and associatedtype for behavior through protocols.

Can a protocol with associatedtype be used as a variable type?

No, Swift does not allow such protocols to be used directly as a type because information about associatedtype is lost. To work around this, you can use type erasure or a generic constraint:

func printElements<C: MyContainer>(container: C) {
    for i in 0..<container.count {
        print(container[i])
    }
}

How to make a protocol with associatedtype a "type" (type erasure)?

This is done using the type erasure pattern — creating a wrapper that stores the internal implementation via closure or box.

struct AnyContainer<T>: MyContainer {
    private let _append: (T) -> Void
    private let _count: () -> Int
    private let _subscript: (Int) -> T
    ... // initialization via closures
}

Common Mistakes and Anti-Patterns

Attempting to use a protocol with associatedtype as a type directly,
Specifying associatedtype unnecessarily — when a generic parameter would be simpler,
Making related types with the same names in different protocols without a clear binding to one type.

Real-life Example

Negative Case

A developer created many protocols with associatedtype for data models, and then tried to create an array let boxes: [MyContainer], but the compiler threw an error. As a result, they had to introduce unnecessary wrappers and lose type safety.

Pros:

Flexibility at the design stage

Cons:

Serious issues with type conversion
Complexity with maintenance and refactoring

Positive Case

In the project, a protocol with associatedtype was used for implementing collections, and a separate type erasure wrapper AnyCollection was created for the abstraction of working with them. This allowed the abstraction from specific collection implementations in the ViewModel layers without losing type safety at the business logic layer.