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

Для обычного требования протокола — нет: тип свойства должен совпадать с типом, указанным в требовании. То, что Int соответствует некоторому протоколу, не позволяет свойству типа Int автоматически реализовать требование свойства типа any ЭтотПротокол.

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

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

Протоколы описывают контракт, через который Swift строит статическое соответствие типа требованиям. Для каждого требования компилятор формирует конкретную реализацию — witness — с совместимой сигнатурой.

Протокольный тип и конкретный тип, соответствующий этому протоколу, имеют разную семантику. any P скрывает конкретный тип за existential-обёрткой, тогда как Int сообщает компилятору точный тип значения.

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

Предположим, протокол требует свойство типа any CustomStringConvertible, а структура объявляет такое же по смыслу свойство типа Int. Хотя Int соответствует CustomStringConvertible, эти свойства имеют разные статические типы.

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

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

Требование свойства с фиксированным типом проверяется по его полной сигнатуре. Тип Int не совпадает с типом any CustomStringConvertible, поэтому более узкий тип результата не является реализацией требования.

Правильный способ выразить такую зависимость — заменить фиксированный протокольный тип на associated type:

protocol ValueProvider {
    associatedtype Value
    var value: Value { get }
}

struct Number: ValueProvider {
    let value: Int
}

Здесь Swift выводит Value == Int. Generic-код, принимающий T: ValueProvider, знает, что у T есть связанный тип T.Value, но не обязан заранее превращать его в any CustomStringConvertible.

Это даёт статическую типобезопасность и сохраняет конкретный тип результата. Компромисс состоит в том, что протокол с associated type нельзя использовать как полностью определённый тип значения без дополнительных механизмов, например type erasure или подходящей existential-поддержки.

Если цель — принимать любые значения, соответствующие протоколу, и конкретный тип результата не важен, в требовании следует явно использовать any CustomStringConvertible. Если же результат должен быть связан с конкретной реализацией, предпочтительнее associatedtype.

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

Допустим, API описывает источник значения. Вариант с требованием any CustomStringConvertible удобен для унифицированного потребителя: он получает один existential-тип. Однако реализация с Int не будет автоматически соответствовать такому требованию, а принудительная упаковка стирает сведения о конкретном типе.

Вариант с associatedtype сохраняет точный тип результата и позволяет generic-алгоритмам выполнять операции, доступные именно для него. Его недостаток — сложнее хранить разные реализации в одной коллекции.

Практический выбор — использовать associatedtype для generic-API, где важна связь источника с его результатом, и any Протокол на границе системы, где нужна гетерогенная коллекция или независимость от конкретного типа. Это разделяет статически типизированную внутреннюю часть и type-erased внешнюю границу.

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

Разве соответствие Int протоколу не делает его подтипом any Протокол?

Нет. Соответствие протоколу означает, что Int реализует требования протокола, но не означает совпадение типов Int и any Протокол. Existential — это отдельный тип-обёртка, способный хранить значение неизвестного конкретного типа.

Можно ли решить проблему, добавив преобразование результата в реализацию свойства?

Да, но преобразование должно быть частью самой реализации с требуемым типом свойства. Например, свойство может возвращать any CustomStringConvertible, создавая existential из внутреннего Int. Простое объявление свойства как Int такого преобразования для соответствия протоколу не добавляет.

Почему associatedtype лучше сохраняет связь между типом и результатом?

Потому что associatedtype является частью конкретного соответствия. Для Number компилятор фиксирует Value == Int, и все члены протокола, использующие Value, согласованы именно с Int. У any ValueProvider конкретный связанный тип скрыт, поэтому такой existential удобен для хранения, но не предоставляет generic-коду ту же статическую связь.