Ответ вслух Senior Протоколы, POP и дженерики обновлено

some и any: opaque и existential типы

Вопрос

Объясните разницу между some и any и как она влияет на производительность и API.

Попробуйте сами

Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.

Показать ответ и разбор

Коротко

some P это opaque type: функция возвращает конкретный тип, который не называет, но он всегда один, и компилятор его знает. Поэтому вызовы специализируются, могут инлайниться, нет упаковки.

Что должно прозвучать в ответе

  • `some P`: один конкретный тип, скрытый от вызывающего, известен компилятору

  • `any P`: existential-контейнер, тип может меняться, динамическая диспетчеризация

  • Existential: inline-буфер 3 слова, иначе упаковка в кучу

  • `some` в параметрах это сахар для дженерика (Swift 5.7)

  • SwiftUI: `some View` сохраняет структуру иерархии для диффинга

  • По умолчанию `some`, `any` когда нужна гетерогенная коллекция

Что могут спросить следом

  • Как получить конкретный тип из any P (открытие existential)?
  • Почему AnyView вредит производительности SwiftUI?

Разбор

some P это opaque type: функция возвращает конкретный тип, который не называет, но он всегда один, и компилятор его знает. Поэтому вызовы специализируются, могут инлайниться, нет упаковки. С Swift 5.7 some можно писать и в параметрах, это сахар для дженерика. any P это existential: значение кладётся в контейнер с inline-буфером на три слова (большее уезжает в кучу), рядом метаданные и witness tables, вызовы динамические. Зато в массиве [any Shape] могут лежать разные типы. Моё правило: по умолчанию some или дженерик, any там, где реально нужна гетерогенность или хранение разных реализаций. В SwiftUI это особенно важно: some View сохраняет статическую структуру дерева, а AnyView её стирает и мешает эффективному сравнению.

Ответьте сами, а не прочитайте

В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.