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

Требование свойства только с get задаёт минимальный контракт: через протокол значение должно быть доступно для чтения. Реализация с get set этот контракт выполняет, потому что предоставляет чтение и дополнительную возможность записи. Обратная замена невозможна: свойство только для чтения не выполняет обязательную часть контракта get set.

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

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

Разделение доступа к свойству на get и set позволяет протоколу выразить намерение не разрешать запись через абстракцию. Это защищает код, работающий с протоколом, от изменения состояния, даже если конкретный тип технически поддерживает запись.

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

Если протокол требует только чтение, пользователь existential-значения или generic-параметра с этим ограничением всё равно не получает доступа к setter. Дополнительная запись, доступная у конкретного типа, не становится частью протокольного интерфейса автоматически.

Если же протокол требует get set, реализация обязана предоставить setter. Иначе generic-код или код через протокол не сможет гарантированно выполнить предусмотренную контрактом запись, что нарушило бы подстановку соответствующего типа.

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

В Swift соответствие проверяется по требованиям протокола. Для свойства с требованием get достаточно члена, поддерживающего чтение. Это может быть константное stored-свойство, вычисляемое свойство только для чтения или изменяемое свойство с setter.

Для требования get set нужны обе операции. Константа или read-only computed property не подходят, поскольку у них отсутствует setter. При этом доступность setter должна позволять выполнить требование протокола: нельзя спрятать обязательную запись более строгим уровнем доступа.

protocol Named {
    var name: String { get }
}

struct User: Named {
    var name: String
}

func printName<T: Named>(_ value: T) -> String {
    value.name
}

User соответствует Named: его свойство изменяемое, но через Named доступно только чтение. Если заменить требование протокола на get set, User всё ещё подойдёт, а тип с let name или read-only свойством — уже нет.

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

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

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

Вариант с get set был бы слишком широким: сервис получил бы право менять состояние. Вариант с отдельным read-only типом уменьшил бы риск записи, но потребовал бы дополнительной обёртки и усложнил модель данных.

Поэтому выбирают get в протоколе и допускают get set в конкретной реализации. Результат — минимальный публичный контракт, совместимый с разными реализациями и защищающий потребителя протокола от нежелательных изменений.

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

Становится ли setter доступен через generic-параметр, если требование протокола содержит только get?

Нет. Generic-код видит только доказанные требования ограничения. Даже если фактический тип имеет изменяемое свойство, параметр T: Named гарантирует лишь чтение. Для записи нужно отдельное требование или работа с конкретным типом.

Может ли let-свойство удовлетворить требованию { get set }?

Нет. let предоставляет только getter. Для соответствия { get set } нужен setter, доступный в требуемом контексте. Поэтому тип с неизменяемым stored-свойством может соответствовать read-only-протоколу, но не протоколу, требующему запись.

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

Соответствие протоколу формирует фиксированный набор требований и доступных через него операций. Swift не меняет статический интерфейс existential-значения или generic-параметра на основании дополнительных членов конкретного типа. Это сохраняет предсказуемость абстракции: код видит ровно контракт протокола, а не случайные возможности текущей реализации.