Implicit opening existentials

1. Граница any и generics

Когда вы впервые начинаете активно использовать any, обычно всё идёт неплохо… ровно до того момента, пока вы не попробуете передать значение any P в generic‑функцию func f<T: P>(_ x: T). И тут Swift внезапно включает режим «строгий преподаватель математики» и выдаёт сообщение, которое звучит как философский парадокс.

Почему появляется ошибка “cannot conform to itself”

Классический пример (максимально учебный, но очень жизненный):

import Foundation

protocol P {
    associatedtype A
    func getA() -> A
}

func takeP<T: P>(_ value: T) {
    _ = value.getA()
}

func test(p: any P) {
    // takeP(p) // ❌ Раньше: "protocol 'P' as a type cannot conform to itself"
}

Почему это вообще происходит? Потому что any P — это не «какой-то конкретный тип, который соответствует P». Это коробка, в которой лежит «что-то, соответствующее P», и внутри может лежать разное в разное время. В Swift‑спецификации эту ситуацию прямо называют ловушкой: легко перейти от generics к existential’ам, но сложно вернуться обратно.

И вот здесь появляется идея implicit opening: «а давайте компилятор сможет временно заглянуть внутрь коробки и подставить конкретный underlying type в generic‑параметр, хотя бы на время одного вызова».

Что значит “открыть existential” по‑человечески

Перед тем как радоваться «ура, компилятор умнеет», важно понять, что именно он делает, и почему это не превращает any P обратно в «нормальный тип» навсегда.

Представьте, что any P — это посылка без наклейки «что внутри». Вы знаете только, что внутри лежит предмет, который соответствует контракту P. Этот предмет — underlying type (конкретный тип, спрятанный внутри existential‑значения).

Implicit opening existentials — это когда в момент конкретного вызова generic‑функции компилятор делает примерно такую мысленную операцию:

1. берёт значение p: any P,
2. «открывает коробку» и видит, что внутри лежит, скажем, IntRepository или FancyCostume,
3. временно подставляет этот underlying type в generic‑параметр T,
4. выполняет вызов как будто вы написали takeP(вот_этот_конкретный_тип),
5. и после вызова не даёт этому «открытому типу» утечь наружу, снова возвращаясь к безопасному «стёртому» миру.

В Swift‑спецификации важная мысль формулируется так: открытие делается, чтобы «сдвинуть» нас от динамически типизированного значения (existential) обратно в статически типизированный generic‑контекст — но локально, внутри вызова.

2. Практика: как вызвать generic‑функцию на [any Repository]

Теперь давайте сделаем пример, который очень напоминает наш курс‑проектный стиль: есть контракт, есть несколько реализаций, мы хотим хранить их «в куче», но обработать через generic‑функцию.

Протокол Repository с associatedtype

import Foundation

protocol Repository {
    associatedtype Item
    func allItems() -> [Item]
}

struct IntRepository: Repository {
    func allItems() -> [Int] { [1, 2, 3] }
}

struct StringRepository: Repository {
    func allItems() -> [String] { ["Swift", "6.2"] }
}

Generic‑функция, которой важна связь R ↔ R.Item

Сделаем generic‑функцию, которая печатает содержимое репозитория. Обратите внимание: внутри функции нам очень удобно, что R.Item связан с R.

import Foundation

func dumpRepository<R: Repository>(_ repo: R) {
    for item in repo.allItems() {
        print("•", item)
    }
}

А теперь — «хранилище разнородных реализаций»:

import Foundation

let repos: [any Repository] = [
    IntRepository(),
    StringRepository()
]

И вот ключевой момент лекции. Мы хотим:

import Foundation

for repo in repos {
    dumpRepository(repo) // implicit opening: открываем underlying type на время вызова
}

С точки зрения концепции, на каждой итерации цикла компилятор делает так: «в этой итерации repo внутри коробки — IntRepository, значит R == IntRepository; в следующей — StringRepository, значит R == StringRepository». Именно такой сценарий и приводится как один из мотивационных для implicit opening: обработка массива [any P] через generic‑функцию.

Почему repo не становится “нормальным типом”

Важно: переменная repo в цикле не становится IntRepository или StringRepository «навсегда». Снаружи она всё ещё any Repository. Открытие живёт только в рамках конкретного вызова dumpRepository(repo).

Это как если бы вы на минуту заглянули в коробку, чтобы понять, что там, сделали действие — и снова закрыли коробку, потому что иначе коробка перестанет быть коробкой, а язык перестанет быть типобезопасным.

3. Почему открытие локальное

Сейчас будет момент, где многие новички говорят: «Окей, компилятор умеет открывать коробку. Значит, я могу… ну… всё?». И вот тут Swift аккуратно забирает у нас лишние надежды.

Открытый тип не должен «утекать» в типовую систему пользователя — иначе начнётся зависимая типизация «тип зависит от значения», а это уже совсем другой уровень сложности. В предложении обсуждается, почему это ломается при мутациях и ветвлениях.

Две коробки — не один T

Пример «почему нельзя сравнить два any Equatable через один T»:

import Foundation

func areSame<T: Equatable>(_ a: T, _ b: T) -> Bool {
    a == b
}

func demo(a: any Equatable, b: any Equatable) {
    // areSame(a, b) // ❌ нельзя: компилятор не может гарантировать один и тот же underlying type для a и b
}

Интуитивно: areSame требует, чтобы оба аргумента были одного конкретного типа T. А any Equatable говорит: «внутри лежит что-то Equatable», но для a и b это «что-то» может быть разным.

В Swift‑спецификации похожий пример приводится через identity и затем сравнение результатов: даже если вы вызываете одну и ту же generic‑функцию на одном и том же existential‑значении, результат после вызова снова type‑erase’ится, и компилятор не считает два результата «статически одним типом».

“Но они же оба Int внутри!” — да, но компилятор не обязан верить

Даже если вы знаете (как человек), что внутри a и b лежит Int, компилятор не может «официально» принять это как факт без доказательства на уровне типов.

Это один из самых важных навыков, который надо тренировать на этом этапе: отличать «я знаю» от «типовая система знает».

4. Диагностика: переводим ошибки компилятора

Вы будете видеть ошибки, которые звучат как:

• protocol 'P' as a type cannot conform to itself

• any P does not conform to P

• cannot convert value of type 'any P' to expected argument type …

• и другие вариации.

И это нормально: компилятор пытается объяснить типовую проблему, а мы пока мыслим сюжетом («ну это же репозиторий, чего ты…»).

Таблица‑переводчик

Ниже — небольшая «таблица‑переводчик» (её удобно держать в заметках).

Откуда логически берётся “cannot conform to itself”

Swift‑спецификация объясняет это прямо: при вызове generic‑функции компилятор раньше пытался подставить T == any P (то есть «пусть T будет коробкой»), но коробка не может соответствовать требованиям, где нужно совпадение конкретного типа. Поэтому и получалось «P как тип не может соответствовать P».

Implicit opening existentials как раз и появился, чтобы в части таких ситуаций компилятор мог не «подставлять коробку», а подставлять underlying type.

Как читать ошибку: ищем “где требуется один конкретный тип”

Когда вы видите страшную диагностику, полезно сделать простую паузу и задать себе два вопроса.

Первый вопрос: «в сигнатуре есть T (или R, или любой generic‑параметр) и он используется один раз или несколько?». Если один раз, то «открытие» часто возможно: компилятору нужно лишь один раз привязать T к underlying type конкретного значения.

Второй вопрос: «я передаю одно значение any P или два?». Если два, то очень часто проблема в том, что два existential‑значения не обязаны иметь один concrete type.

5. Swift 6: ограничения implicit opening

Эта часть кажется мелкой, пока вы не встретите её в реальном коде — а потом она превращается в «почему перестановка аргументов сломала компиляцию». Поэтому лучше узнать об этом в спокойной обстановке, сейчас.

В Swift важно, что аргументы функции вычисляются слева направо. А чтобы «открыть» existential, компилятору иногда нужно вычислить аргумент (получить коробку), заглянуть внутрь и только потом типизировать другие аргументы. Если это ломает порядок вычисления — Swift запрещает такое открытие. В предложении этот момент разбирается с примером, где открытие потребовало бы выполнить getP() раньше hello(), что нарушило бы привычный порядок.

Почему перестановка параметров может ломать компиляцию

Суть не в том, что именно тут написано, а в том, что generic‑параметр, который «привязывается» к opened existential, не должен быть нужен для аргументов, которые идут раньше в списке.

Если вы видите ошибку, которая исчезает при перестановке аргументов, это часто именно оно: компилятор не может одновременно сохранить left‑to‑right и сделать implicit opening там, где ему нужно.

Как подавить opening через as any P

Иногда разработчику нужно запретить implicit opening (например, чтобы сохранить старую семантику, или чтобы явно признать «я теряю ограничения, делая type erasure»). Для этого обсуждается приём: сделать явное приведение к existential прямо в аргументе, например p as any P.

Но есть хитрый момент: дополнительные скобки могут менять поведение подавления (то есть getP((x as any P)) может вести себя иначе, чем getP(x as any P)), и в тексте предложения прямо приводится пример, где скобки помогают обойти конфликт «мне нужно as any P из‑за потери ограничения, но оно же подавляет opening».

На уровне курса вам не нужно запоминать все эти нюансы как заклинания. Достаточно понимать идею: «implicit opening — это не “магия без правил”, у него есть ограничения ради предсказуемости языка».

6. Типичные ошибки

Ошибка №1: ожидать, что implicit opening “починит” любые проблемы any.
Implicit opening решает довольно конкретную боль: «у меня есть existential, я хочу вызвать generic‑функцию, и компилятору достаточно знать underlying type только внутри вызова». Но если вы хотите, чтобы этот тип сохранился между вызовами, чтобы два значения гарантированно были одного underlying type, или чтобы можно было хранить что-то и потом безопасно доставать типизированно — это уже другая задача. Тут implicit opening не всемогущ, и это нормально.

Ошибка №2: не замечать, что один generic‑параметр используется несколько раз.
Очень многие «страшные» ошибки на самом деле про одну простую вещь: T встречается дважды, значит оба места должны быть одним конкретным типом. Как только вы видите сигнатуру вроде func f<T>(_: T, _: T), мысленно включайте лампочку: «один и тот же T». С any это часто означает конфликт, потому что две коробки не обязаны содержать одинаковые типы.

Ошибка №3: пытаться лечить диагностику форс‑кастами as!.
Когда код не компилируется, рука тянется к «ну я-то знаю, что там Int!». Но as! здесь почти всегда превращает типовую проблему в потенциальный краш в рантайме. А ещё вы закрепляете плохой дизайн: получается, что ваш API требует одних гарантий, а вы проталкиваете другие «силой». Лучше остановиться и спросить: «мне нужен any здесь или мне нужен generic‑параметр?».

Ошибка №4: путать “коробка соответствует протоколу” и “значение в коробке соответствует протоколу”.
Это тонкая мысль, но она — сердцевина темы. Внутри any P лежит значение, которое соответствует P. Но сам any P как тип не обязан соответствовать P, особенно если в протоколе есть Self/associatedtype‑связи. Именно отсюда растут сообщения «cannot conform to itself» и именно это лечит (частично) implicit opening, открывая коробку внутри вызова.