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

Swift разрешает непадающему инициализатору реализовать требование с init?, потому что он сильнее по гарантии: он всегда создаёт значение, тогда как вызывающий код требования допускает как успешное создание, так и nil.

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

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

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

Такой подход позволяет разным типам иметь различную строгость создания, сохраняя единый интерфейс. Реализация не обязана искусственно возвращать nil, если отказ в ней невозможен.

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

В примере вызывающий код работает с результатом типа Header?, потому что контракт DecodablePacket допускает неудачное декодирование. Однако Header реализует инициализацию без ? и не может вернуть nil.

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

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

При проверке соответствия Swift рассматривает непадающий инициализатор как допустимый witness для падающего требования. При вызове через протокол результат представляется в форме, указанной требованием: успешное создание Header превращается в значение Header?, содержащее объект.

Упрощённо механизм можно представить так:

protocol DecodablePacket {
    init?(bytes: [UInt8])
}

struct Header: DecodablePacket {
    init(bytes: [UInt8]) { }
}

func decode<T: DecodablePacket>(_ type: T.Type) -> T? {
    T(bytes: [1, 2, 3])
}

Вызов T(bytes:) внутри generic-кода имеет тип T?, поскольку он определяется требованием протокола. Конкретный Header при этом использует свой обычный init, а адаптация к падающему контракту выполняется на уровне вызова witness.

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

Это правило относится именно к совместимости падающего и непадающего инициализаторов. throws — отдельный механизм обработки ошибок и автоматически не заменяет init? или обычный init в требованиях протокола.

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

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

Можно объявить протокол с init?, чтобы единый generic-код безопасно обрабатывал все варианты. Альтернатива — объявить обычный init и использовать исключения через throws, но это изменит модель ошибок и заставит все реализации поддерживать другой контракт.

Выбранное решение с init? оправдано, если ошибка декодирования является ожидаемым результатом, а не исключительной ситуацией. Типы с гарантированно корректными входными данными получают простую реализацию без искусственного nil, а общий код сохраняет единый optional-результат.

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

Может ли init? реализовать обычное требование init?

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

Меняется ли тип вызова при обращении к конкретному типу напрямую?

Да. Вызов Header(bytes: ...) использует объявленный у Header обычный инициализатор и возвращает Header. Через ограничение T: DecodablePacket тот же синтаксис имеет результат T?, потому что статический контракт generic-параметра содержит init?.

Должна ли реализация класса с таким требованием быть required?

Если соответствие протоколу реализует класс и инициализатор объявлен в самом классе, он обычно должен быть required, чтобы подклассы сохраняли возможность удовлетворять тому же протокольному контракту. Для структуры Header это правило не применяется: структуры не имеют наследников.