Краткий ответ

Да. typealias сохраняет условное соответствие, потому что не создаёт новый тип, а только даёт существующему типу другое имя. Если конкретный аргумент generic-типа удовлетворяет условию соответствия, специализированный тип через typealias также удовлетворяет протоколу.

Исторический контекст

В Swift generic-типы позволяют описывать один алгоритм для множества типов, а условные соответствия — объявлять соответствие протоколу только при выполнении ограничений для параметров. typealias решает другую задачу: делает сложные типы короче и понятнее, не вводя новую номинальную сущность.

Такое разделение важно: псевдоним не должен изменять систему типов или заново объявлять доступные соответствия.

Постановка проблемы

Разработчик может ошибочно воспринимать typealias как новый тип и ожидать, что его соответствия протоколам нужно объявлять отдельно. Это приводит к лишним объявлениям или к неверному выводу, будто псевдоним может получить соответствие независимо от ограничений generic-параметра.

Ключевой риск связан с условием: псевдоним специализированного типа получает соответствие только тогда, когда фактический параметр удовлетворяет условию. Сам typealias не отменяет и не ослабляет generic-ограничение.

Подробное решение

Рассмотрим условное соответствие контейнера Box протоколу Equatable:

struct Box<Value> {
    let value: Value
}

extension Box: Equatable where Value: Equatable {}

typealias IntBox = Box<Int>

let first = IntBox(value: 1)
let second = IntBox(value: 1)
let equal = first == second

IntBox — это не отдельный тип, а другое имя для Box<Int>. Поскольку Int соответствует Equatable, условие Value: Equatable выполнено, поэтому Box<Int> и, следовательно, IntBox имеют это соответствие.

Если объявить typealias AnyBox = Box<Any>, соответствие не появится: Any не удовлетворяет требованию Equatable. Псевдоним не может подменить фактический аргумент или создать соответствие без выполнения условия.

Это отличается от обёртки. Новая структура с полем Box<Int> была бы самостоятельным номинальным типом: она не получила бы соответствия автоматически и потребовала бы собственного объявления. Такой подход полезен, когда нужно отделить семантику, API или ограничения нового типа.

Практическое следствие: typealias удобно использовать для читаемости и повторного применения сложных специализаций, но не для создания нового доменного типа или изменения его протокольных гарантий.

Ситуация из практики

В библиотеке есть тип PagedStorage<Element>, который соответствует Collection только при выполнении ограничений для Element. Команда вводит typealias UserStorage = PagedStorage<User> и хочет передавать его в generic-функцию, принимающую Collection.

Вариант с прямым использованием PagedStorage<User> корректен, но ухудшает читаемость публичного API. Вариант с typealias сохраняет все соответствия и ограничения исходной специализации, поэтому является подходящим решением, если UserStorage не должен быть отдельным типом.

Если же UserStorage должен запрещать операции исходного контейнера, иметь собственные инварианты или отличаться по смыслу от PagedStorage<User>, нужен wrapper-тип. Он требует явных соответствий, зато создаёт отдельную границу абстракции. В описанной ситуации выбран typealias: поведение не меняется, а тип API становится понятнее.

Что кандидаты часто упускают

Может ли typealias ослабить условие условного соответствия?

Нет. Если соответствие объявлено для Container<Element> при условии Element: Hashable, псевдоним typealias Names = Container<String> будет соответствовать протоколу только потому, что String удовлетворяет этому условию. Псевдоним для Container<SomeType> без нужного соответствия не получает протокол автоматически.

Создаёт ли typealias новый тип для перегрузки функций?

Нет. Функции, принимающие исходный тип и его typealias, не получают два независимых варианта перегрузки: для компилятора это один и тот же тип. Чтобы различать значения на уровне типовой системы, нужна новая структура, перечисление или класс.

Нужно ли повторно объявлять соответствие протоколу для typealias?

Нет, если соответствие уже доступно исходному типу после подстановки конкретных generic-аргументов. Повторное объявление не создаёт нового поведения и может привести к конфликту или дублированию соответствия. Отдельное объявление требуется только для нового номинального wrapper-типа, а не для псевдонима.