Associated types и продвинутые протоколы — бесплатный тест онлайн

Вопрос 1 из 25

Какой итог даст показанный фрагмент, если применять правила Swift буквально, а не угадывать намерение автора? Здесь оценивается вывод связанного типа и его влияние на использование протокола.

protocol Storage {
    associatedtype Item
    mutating func add(_ item: Item)
}
struct IntStore: Storage {
    var items: [Int] = []
    mutating func add(_ item: Int) { items.append(item) }
}

Компилятор выводит Item как Int из сигнатуры add, явный typealias не требуется. Операция с `add` корректна, поскольку стирание типа устраняет стоимость динамического вызова и правила владения. Компилятор выводит Item как Int из сигнатуры add, явный typealias требуется. Для этого примера достаточно учесть, что `associatedtype` выбирается заново при каждом вызове метода. Последняя строка ведёт себя именно так, потому что `some P` позволяет возвращать разные конкретные типы из каждой ветви.

Вопрос 2 из 25

Определите не предполагаемое, а фактическое поведение примера «Экзистенциальные типы any». Не упускайте из виду следующее: упаковка значения и потеря части статической информации.

protocol Renderable { func render() -> String }
struct Text: Renderable { let value: String; func render() -> String { value } }
let items: [any Renderable] = [Text(value: "A")]
print(items[0].render())

Existential не позволяет хранить разнородные соответствующие значения; вызов печатает «A». Existential позволяет хранить разнородные соответствующие значения; вызов печатает «nil». Наблюдаемый результат определяется тем, что `some P` позволяет возвращать разные конкретные типы из каждой ветви. Операция с `render` корректна, поскольку `any P` сохраняет конкретный тип так же, как generic-параметр `T: P`. Existential позволяет хранить разнородные соответствующие значения; вызов печатает «A».

Вопрос 3 из 25

Какой из пяти выводов подтверждается построчной трассировкой? Не упускайте из виду следующее: направление сокрытия типа и допустимость смешивания реализаций.

protocol Animal { func sound() -> String }
struct Cat: Animal { func sound() -> String { "meow" } }
func pet() -> some Animal { Cat() }
let a: any Animal = pet()
print(a.sound())

Функция не возвращает скрытый конкретный Cat, который затем упаковывается в any Animal; печатается «meow». Операция с `sound` корректна, поскольку `some P` позволяет возвращать разные конкретные типы из каждой ветви. Функция возвращает скрытый конкретный Cat, который затем упаковывается в any Animal; печатается «meow». Функция возвращает скрытый конкретный Cat, который затем упаковывается в some Animal; печатается «meow». Для этого примера достаточно учесть, что `any P` сохраняет конкретный тип так же, как generic-параметр `T: P`.

Вопрос 4 из 25

Что увидит разработчик после выполнения этого примера по теме «Стирание типа»? Проверяется цель и безопасная реализация стирания типа.

struct AnyIteratorBox<Element>: IteratorProtocol {
    private var nextImpl: () -> Element?
    init<I: IteratorProtocol>(_ iterator: I) where I.Element == Element {
        var iterator = iterator
        nextImpl = { iterator.next() }
    }
    mutating func next() -> Element? { nextImpl() }
}

Наблюдаемый результат определяется тем, что стирание типа устраняет стоимость динамического вызова и правила владения. Операция с `AnyIteratorBox` корректна, поскольку `associatedtype` выбирается заново при каждом вызове метода. Обёртка не сохраняет конкретный итератор внутри замыкания и предоставляет единый внешний тип с тем же Element. Фрагмент не требует отдельного условия: экзистенциальный контейнер всегда предпочтительнее generic-сигнатуры. Обёртка сохраняет конкретный итератор внутри замыкания и предоставляет единый внешний тип с тем же Element.

Вопрос 5 из 25

Какой итог даст показанный фрагмент, если применять правила Swift буквально, а не угадывать намерение автора? Не упускайте из виду следующее: локализация ошибки между existential, generic и связанным типом.

func count<S: Sequence>(_ values: S) -> Int { values.reduce(0) { n, _ in n + 1 } }
print(count([1, 2, 3]))

Операция с `count` корректна, поскольку экзистенциальный контейнер всегда предпочтительнее generic-сигнатуры. Generic-функция открывает конкретный тип параллельности и печатает 3. Generic-функция открывает конкретный тип последовательности и печатает 4. Generic-функция открывает конкретный тип последовательности и печатает 3. Для этого примера достаточно учесть, что стирание типа устраняет стоимость динамического вызова и правила владения.

Вопрос 6 из 25

Какой диагноз согласуется и с исходным кодом, и с правилами Swift? Проверяется вывод связанного типа и его влияние на использование протокола.

protocol Factory { associatedtype Product; func make() -> Product }
struct Broken: Factory { func make() -> Int? { nil } }
let x: any Factory = Broken()

Причина сбоя в том, что `associatedtype` выбирается заново при каждом вызове метода. Соответствие само по себе вознельзя с Product == Int?, но через existential результат теряет удобный конкретный тип без дополнительного открытия. Проблема возникает из-за правила: `some P` позволяет возвращать разные конкретные типы из каждой ветви. Отчёт об ошибке должен указывать, что `any P` сохраняет конкретный тип так же, как generic-параметр `T: P`. Соответствие само по себе возможно с Product == Int?, но через existential результат теряет удобный конкретный тип без дополнительного открытия.

Вопрос 7 из 25

Что именно делает этот фрагмент неверным или неочевидным с точки зрения «Экзистенциальные типы any»? Здесь оценивается упаковка значения и потеря части статической информации.

protocol CopyableItem { associatedtype Copy; func copy() -> Copy }
func duplicate(_ value: any CopyableItem) {
    let x: CopyableItem.Copy = value.copy()
}

Код не компилируется: у existential нет единого доступного имени CopyableItem.Copy без открытия конкретного типа. Проблема возникает из-за правила: `some P` позволяет возвращать разные конкретные типы из каждой ветви. Код компилируется: у existential нет единого доступного имени CopyableItem.Copy без открытия конкретного типа. Отчёт об ошибке должен указывать, что `any P` сохраняет конкретный тип так же, как generic-параметр `T: P`. Код проходит проверку типов: у existential нет единого доступного имени CopyableItem.Copy без открытия конкретного типа.

Вопрос 8 из 25

Почему этот код не выполняет заявленный контракт? Сосредоточьтесь на следующем: направление сокрытия типа и допустимость смешивания реализаций.

protocol Marker {}
struct M1: Marker {}
struct M2: Marker {}
let values: [some Marker] = [M1(), M2()]

Причина сбоя в том, что `associatedtype` выбирается заново при каждом вызове метода. Код компилируется и проходит проверку типов: один opaque тип в позиции массива должен быть одним конкретным типом, а элементы различны. Код не компилируется: один opaque тип в позиции массива должен быть одним конкретным типом, а элементы различны. Проблема возникает из-за правила: `some P` позволяет возвращать разные конкретные типы из каждой ветви. Код компилируется: один opaque тип в позиции массива должен быть одним конкретным типом, а элементы различны.

Вопрос 9 из 25

Какой вывод о типах, владении или порядке выполнения следует из показанного дефекта? Проверяется цель и безопасная реализация стирания типа.

struct BadBox<Element> {
    let base: Any
    func next() -> Element? { (base as! any IteratorProtocol).next() as? Element }
}

Причина сбоя в том, что `associatedtype` выбирается заново при каждом вызове метода. Такое стирание небезопасно и к тому же не компилируется корректно: inout next нельзя вызвать на неизменяемом existential без управляемого хранилища. Такое стирание небезопасно и к тому же компилируется корректно: mutating next нельзя вызвать на неизменяемом existential без управляемого хранилища. Такое стирание небезопасно и к тому же не компилируется корректно: mutating next нельзя вызвать на неизменяемом existential без управляемого хранилища. Такое стирание небезопасно и к тому же компилируется и проходит проверку типов корректно: mutating next нельзя вызвать на неизменяемом existential без управляемого хранилища.

Вопрос 10 из 25

Разработчик видит симптом, но ищет первопричину. Какое объяснение выдерживает проверку кодом? Проверяется локализация ошибки между existential, generic и связанным типом.

protocol Source { associatedtype Element; func all() -> [Element] }
func inspect(_ source: any Source) {
    let values: [Int] = source.all()
}

Код проходит проверку типов: existential не гарантирует, что Element равен Int. Код компилируется: existential не гарантирует, что Element равен Int. Наблюдаемый симптом объясняется тем, что `associatedtype` выбирается заново при каждом вызове метода. Код не компилируется: existential не гарантирует, что Element равен Int. Отчёт об ошибке должен указывать, что стирание типа устраняет стоимость динамического вызова и правила владения.

Вопрос 11 из 25

Какое изменение устраняет именно показанную причину и сохраняет ясный контракт «Связанные типы associatedtype»? Проверяется вывод связанного типа и его влияние на использование протокола.

protocol Factory { associatedtype Product; func make() -> Product }
struct Broken: Factory { func make() -> Int? { nil } }
let x: any Factory = Broken()

Достаточно изменить работу с `make`, исходя из того, что `associatedtype` выбирается заново при каждом вызове метода. На границе API решить, нужна ли статическая обобщённая функция, opaque type или existential с неявным ограничением associated type. Правка сводится к локальному обходу: стирание типа устраняет стоимость динамического вызова и правила владения. На границе API решить, нужна ли статическая обобщённая функция, opaque type или existential с явным ограничением associated type. Сигнатуру можно не менять, если считать, что экзистенциальный контейнер всегда предпочтительнее generic-сигнатуры.

Вопрос 12 из 25

Какая правка делает намерение кода явным и проверяемым? Важно учесть: упаковка значения и потеря части статической информации.

protocol CopyableItem { associatedtype Copy; func copy() -> Copy }
func duplicate(_ value: any CopyableItem) {
    let x: CopyableItem.Copy = value.copy()
}

Достаточно изменить работу с `copy`, исходя из того, что `some P` позволяет возвращать разные конкретные типы из каждой ветви. Сигнатуру можно не менять, если считать, что стирание типа устраняет стоимость динамического вызова и правила владения. Сделать функцию generic — не func duplicate<T: CopyableItem>(_ value: T) — либо стереть тип результата осознанно. Сделать функцию generic — func duplicate<T: CopyableItem>(_ value: T) — либо стереть тип результата осознанно. Правка сводится к локальному обходу: `associatedtype` выбирается заново при каждом вызове метода.

Вопрос 13 из 25

Как восстановить заявленный контракт с наименьшим числом новых скрытых предположений? Сосредоточьтесь на следующем: направление сокрытия типа и допустимость смешивания реализаций.

protocol Marker {}
struct M1: Marker {}
struct M2: Marker {}
let values: [some Marker] = [M1(), M2()]

Использовать [any Marker] для разнородной коллекции либо общий enum/обёртку, если набор вариантов контролируется. Сигнатуру можно не менять, если считать, что `any P` сохраняет конкретный тип так же, как generic-параметр `T: P`. Использовать [some Marker] для разнородной коллекции либо общий enum/обёртку, если набор вариантов контролируется. Правка сводится к локальному обходу: экзистенциальный контейнер всегда предпочтительнее generic-сигнатуры. Нужно адаптировать только вызов `M1`, поскольку `some P` позволяет возвращать разные конкретные типы из каждой ветви.

Вопрос 14 из 25

Какое изменение устраняет именно показанную причину и сохраняет ясный контракт «Стирание типа»? Здесь оценивается цель и безопасная реализация стирания типа.

struct BadBox<Element> {
    let base: Any
    func next() -> Element? { (base as! any IteratorProtocol).next() as? Element }
}

Достаточно изменить работу с `BadBox`, исходя из того, что `associatedtype` выбирается заново при каждом вызове метода. Правка сводится к локальному обходу: стирание типа устраняет стоимость динамического вызова и правила владения. Нужно адаптировать только вызов `BadBox`, поскольку `any P` сохраняет конкретный тип так же, как generic-параметр `T: P`. Исправление — оставить контракт прежним и учитывать, что `some P` позволяет возвращать разные конкретные типы из каждой ветви. Стереть только необходимые операции в замыкания или приватную коробку, сохранив тип Element статически.

Вопрос 15 из 25

Как восстановить заявленный контракт с наименьшим числом новых скрытых предположений? Проверяется локализация ошибки между existential, generic и связанным типом.

protocol Source { associatedtype Element; func all() -> [Element] }
func inspect(_ source: any Source) {
    let values: [Int] = source.all()
}

Добавить primary associated type/ограничение вида any Source<Int>, где оно поддерживается контрактом, либо сделать inspect generic. Нужно адаптировать только вызов `all`, поскольку экзистенциальный контейнер всегда предпочтительнее generic-сигнатуры. Исправление — оставить контракт прежним и учитывать, что `any P` сохраняет конкретный тип так же, как generic-параметр `T: P`. Сигнатуру можно не менять, если считать, что стирание типа устраняет стоимость динамического вызова и правила владения. Добавить primary associated type/ограничение вида some Source<Int>, где оно поддерживается контрактом, либо сделать inspect generic.

Вопрос 16 из 25

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

generic-параметр является заполнителем, который выбирает соответствующий тип, а не новым generic-параметром каждого вызова метода. associatedtype является заполнителем, который выбирает соответствующий тип, а не новым generic-параметром каждого вызова метода. Ограничение определяется предположением, что `associatedtype` выбирается заново при каждом вызове метода. associatedtype не является заполнителем, который выбирает соответствующий тип, а не новым generic-параметром каждого вызова метода. associatedtype является заполнителем, который выбирает соответствующий тип, а новым generic-параметром каждого вызова метода.

Вопрос 17 из 25

Какое условие отличает надёжное обобщение от случайно удачного запуска? Проверяется упаковка значения и потеря части статической информации.

Ограничение определяется предположением, что `associatedtype` выбирается заново при каждом вызове метода. any P имеет собственную стоимость упаковки и динамического вызова; generic T: P сохраняет конкретный тип в каждой специализации. some P имеет собственную стоимость упаковки и динамического вызова; generic T: P сохраняет конкретный тип в каждой специализации. any P имеет собственную стоимость упаковки и динамического вызова; generic T: P не сохраняет конкретный тип в каждой специализации. Правило меняется только в ситуации, где `some P` позволяет возвращать разные конкретные типы из каждой ветви.

Вопрос 18 из 25

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

some не выбирается производителем и остаётся одним типом; any выбирается во время выполнения для каждого значения. Ограничение определяется предположением, что `some P` позволяет возвращать разные конкретные типы из каждой ветви. some выбирается производителем и остаётся одним типом; some выбирается во время выполнения для каждого значения. any выбирается производителем и остаётся одним типом; any выбирается во время выполнения для каждого значения. some выбирается производителем и остаётся одним типом; any выбирается во время выполнения для каждого значения.

Вопрос 19 из 25

Какое ограничение темы «Стирание типа» обязательно проверить отдельным граничным тестом? Здесь оценивается цель и безопасная реализация стирания типа.

Граница применимости проходит там, где экзистенциальный контейнер всегда предпочтительнее generic-сигнатуры. Ограничение определяется предположением, что `associatedtype` выбирается заново при каждом вызове метода. Type erasure скрывает конкретную реализацию, но не отменяет семантику владения, мутацию и стоимость динамической диспетчеризации. Контрпример появляется, когда стирание типа устраняет стоимость динамического вызова и правила владения. Type erasure скрывает конкретную реализацию, но отменяет семантику владения, мутацию и стоимость динамической диспетчеризации.

Вопрос 20 из 25

Какую предпосылку стоит явно записать в документации и тестах? Проверяется локализация ошибки между existential, generic и связанным типом.

Правило меняется только в ситуации, где `associatedtype` выбирается заново при каждом вызове метода. При диагностике важно выписать, какая сторона выбирает associated type и где эта информация теряется. Граница применимости проходит там, где `any P` сохраняет конкретный тип так же, как generic-параметр `T: P`. Контрпример появляется, когда экзистенциальный контейнер всегда предпочтительнее generic-сигнатуры. Пограничный случай связан с тем, что `some P` позволяет возвращать разные конкретные типы из каждой ветви.

Вопрос 21 из 25

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

Протокол с generic-параметр удобен для семейств связанных операций; как универсальный контейнер он часто требует дополнительной обёртки. Протокол с associatedtype удобен для семейств связанных операций; как универсальный контейнер он часто требует дополнительной обёртки. Для устойчивого решения достаточно принять, что `associatedtype` выбирается заново при каждом вызове метода. Протокол с associatedtype удобен для семейств связанных операций; как универсальный контейнер он часто не требует дополнительной обёртки. В API и тестах следует исходить из правила: стирание типа устраняет стоимость динамического вызова и правила владения.

Вопрос 22 из 25

Как организовать этот механизм, чтобы владение и отказ оставались понятными после расширения проекта? Сосредоточьтесь на следующем: упаковка значения и потеря части статической информации.

Главным проектным принципом здесь является утверждение, что `any P` сохраняет конкретный тип так же, как generic-параметр `T: P`. При расширении системы нужно опираться на то, что `some P` позволяет возвращать разные конкретные типы из каждой ветви. Existential полезен для разнородного хранения и позднего выбора реализации, но не должен применяться автоматически ко всем протоколам. Existential полезен для разнородного хранения и позднего выбора реализации, но должен применяться автоматически ко всем протоколам. В API и тестах следует исходить из правила: экзистенциальный контейнер всегда предпочтительнее generic-сигнатуры.

Вопрос 23 из 25

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

Выбор между some и any — это выбор владения абстракцией: кто определяет конкретный тип и нужна ли разнородность. Главным проектным принципом здесь является утверждение, что стирание типа устраняет стоимость динамического вызова и правила владения. Выбор между some и some — это выбор владения абстракцией: кто определяет конкретный тип и нужна ли разнородность. Выбор между some и any — не это выбор владения абстракцией: кто определяет конкретный тип и нужна ли разнородность. Выбор между any и any — это выбор владения абстракцией: кто определяет конкретный тип и нужна ли разнородность.

Вопрос 24 из 25

Какой принцип важнее локальной красоты синтаксиса в рабочем приложении? Проверяется цель и безопасная реализация стирания типа.

Архитектуру стоит строить из предположения, что `some P` позволяет возвращать разные конкретные типы из каждой ветви. Собственную стирающую обёртку стоит писать лишь когда стандартных AnySequence, AnyPublisher и подобных типов недостаточно. В API и тестах следует исходить из правила: стирание типа устраняет стоимость динамического вызова и правила владения. При расширении системы нужно опираться на то, что `any P` сохраняет конкретный тип так же, как generic-параметр `T: P`. Для устойчивого решения достаточно принять, что `associatedtype` выбирается заново при каждом вызове метода.

Вопрос 25 из 25

Что должно определять архитектуру этого участка, когда появятся новые входы и владельцы? Сосредоточьтесь на следующем: локализация ошибки между existential, generic и связанным типом.

Надёжнее стереть все реализации в `Any` и сравнивать только факт успешного приведения типа. Тесты должны включать минимум две разные реализации протокола, иначе случайная привязка к одному конкретному типу останется незаметной. Одного возвращаемого `some P` достаточно для проверки разнородного хранения реализаций. Тесты следует строить только через `any P`, чтобы конкретный тип никогда не участвовал в проверке. Достаточно проверить одну реализацию: соответствие протоколу уже доказывает одинаковое поведение всех остальных типов.