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

Generic-код может вызвать инициализатор параметра типа только тогда, когда этот инициализатор объявлен требованием протокола или гарантирован другим generic-ограничением. Само соответствие протоколу не даёт доступа ко всем инициализаторам конкретного типа.

Если протокол требует init(), функция с ограничением T: Protocol может создать T() независимо от конкретной реализации. Если такого требования нет, компилятор не может доказать, что у каждого допустимого типа существует нужный инициализатор.

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

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

Протоколы дополняют generics контрактами: generic-код получает доступ не к произвольным членам типа, а только к явно гарантированным требованиям. Инициализатор является таким же требованием, как метод или свойство, поэтому его нужно объявить в протоколе отдельно.

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

Рассмотрим generic-фабрику, которая должна создать объект, имея только его тип. Если ограничение указывает лишь соответствие протоколу, но протокол не требует подходящего инициализатора, вызов инициализатора недопустим.

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

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

Инициализатор можно вызвать через generic-параметр, если он входит в контракт ограничения:

protocol Resettable {
    init()
}

struct Session: Resettable {
    init() {}
}

func make<T: Resettable>(_ type: T.Type) -> T {
    T()
}

let session = make(Session.self)

Здесь T() корректен, потому что компилятор знает: любой тип T, допустимый в функции, обязан реализовать init(). Конкретный инициализатор Session может выполнять дополнительные действия, но его наличие гарантируется протоколом.

Если протокол содержит только метод или свойство, это не подразумевает наличие инициализатора. Например, соответствие Resettable нельзя заменить соответствием произвольному протоколу с методом reset(): сброс существующего объекта и создание нового — разные операции.

Для классов требуемый протоколом инициализатор обычно объявляют с required, чтобы наследники также сохраняли возможность удовлетворить контракт. Для final-класса это требование к наследованию не имеет практического смысла, но сам инициализатор всё равно должен соответствовать протоколу.

Вызов через метатип T.Type также подчиняется этому правилу. Generic-ограничение даёт доступ только к статическим членам и инициализаторам, объявленным в протоколе или доказанным дополнительными ограничениями; публичный инициализатор конкретного типа сам по себе не становится частью интерфейса T.

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

Команде нужна generic-фабрика для создания объектов экрана. Рассматривались три варианта: требовать в протоколе пустой инициализатор, передавать фабричное замыкание или использовать конкретный тип.

Пустой инициализатор прост и хорошо подходит, если создание не требует зависимостей. Фабричное замыкание гибче: оно позволяет передать конфигурацию, зависимости и асинхронную логику, но усложняет вызов и переносит часть контракта из типов в значение. Конкретный тип даёт максимум контроля, но полностью устраняет переиспользование generic-алгоритма.

Если всем реализациям действительно достаточно стандартного создания, выбирают требование инициализатора в протоколе. Если объекту нужны сервисы или параметры окружения, предпочтительнее передать фабрику; добавлять искусственный пустой инициализатор в этом случае не стоит. Так контракт отражает реальную модель создания, а не только удобство одной функции.

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

1. Достаточно ли объявить инициализатор только в extension протокола?

Нет, если generic-код должен использовать его как обязательную возможность каждого соответствующего типа. Инициализатор в extension может быть реализацией default implementation уже существующего требования, но сам по себе не превращает новый член в обязательное требование протокола.

Чтобы вызов через T был гарантирован, инициализатор должен быть записан в основном объявлении протокола. Тогда соответствие конкретного типа проверяется с учётом этого требования.

2. Почему наличие публичного init() у конкретного типа не помогает generic-функции?

Generic-функция компилируется для всех типов, удовлетворяющих её ограничениям, а не только для известного вызывающему кода типа. Если ограничение содержит лишь T: P, компилятор может использовать только требования P.

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

3. Чем отличается требование init() в протоколе от конкретного типа-фабрики?

Требование init() гарантирует единый способ создания для всех соответствующих типов, но не позволяет передавать параметры и зависимости, если они не описаны в сигнатуре требования. Конкретная фабрика может создавать разные реализации и использовать произвольную логику, однако её контракт проверяется слабее средствами самого протокола.

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