Ответ.

История вопроса: Type erasure (стирание типа) — паттерн, который появился в Swift как ответ на ограничения протоколов с associated type или Self requirements. Протокол нельзя использовать в качестве типа напрямую без type erasure, если он содержит связанные типы, поскольку компилятор не знает конкретную реализацию. Этим часто сталкиваются при создании контейнеров данных, коллекций, потоков, где важна абстракция.

Проблема: Если есть протокол с associatedtype, например:

protocol Animal {
    associatedtype Food
    func eat(_ food: Food)
}

нельзя объявить переменную типа Animal. Нам нужен "стирающий оболочку" тип, который позволяет обращаться к разным конкретным типам через абстракцию:

let zoo: [any Animal] // Ошибка компиляции

Решение: Type erasure реализуется с помощью оберток (например, Box паттерн или struct AnyXxx), предоставляя единый интерфейс, скрывая детали реального типа:

struct AnyAnimal<F>: Animal {
    private let _eat: (F) -> Void
    init<A: Animal>(_ base: A) where A.Food == F {
        _eat = base.eat
    }
    func eat(_ food: F) { _eat(food) }
}

Теперь можно хранить разные реализации Animal с одинаковым Food:

let animals: [AnyAnimal<Grass>] = [AnyAnimal(Cow()), AnyAnimal(Sheep())]

Ключевые особенности:

Позволяет работать с протоколами с associatedtype как с обычным типом
Решает задачу универсальных контейнеров и фабрик протокольных сущностей
Является архитектурным паттерном для сокрытия деталей реализации

Вопросы с подвохом.

Можно ли использовать протокол с associatedtype без type erasure как тип свойства или массива?

Нет, нельзя. Компилятор требует конкретизацию всех связанных типов. Например, следующая запись вызовет ошибку:

let array: [Animal] // Error: 'Animal' can only be used as a generic constraint

Может ли type erasure заменить наследование?

Нет, type erasure не является полной заменой наследованию. Он решает задачу абстракции для протоколов с associatedtype, а наследование используется для реализации общей логики и переиспользования кода между классами.

Нужно ли реализовывать все методы и свойства протокола внутри type erasure оболочки?

Да, обязательно. Type erasure работает, только если обертка полностью повторяет внешний интерфейс протокола, иначе часть функционала будет недоступна.

Типовые ошибки и анти-паттерны

Забывают реализовать все методы/свойства, что приводит к silent loss функциональности
Используют type erasure там, где можно обойтись без него (например, если нет associatedtype)
Создают избыточные или слишком сложные оболочки, снижающие читаемость

Пример из жизни

Негативный кейс

В боевом проекте вся работа с источниками данных строится через type erasure, даже когда нет нужды в associatedtype. Код становится сложно поддерживать, новые разработчики путаются.

Плюсы:

Универсальность API

Минусы:

Понижение читаемости, усложнение архитектуры, латентные баги

Позитивный кейс

Type erasure применяется только для абстракции источника данных, который инкапсулирует разные стратегии загрузки (сетевые, локальные), каждая со своими типами. В остальном код прозрачен.