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

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

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

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

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

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

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

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

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

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

При переопределении read-write-свойства подкласс должен предоставить и getter, и setter. Реализация может быть вычисляемой, а обращение к реализации базового класса обычно выполняется через super.

class Base {
    var value: Int {
        get { 0 }
        set { print(newValue) }
    }
}

class Child: Base {
    override var value: Int {
        get { super.value }
        set { super.value = newValue * 2 }
    }
}

Здесь контракт сохранён: через ссылку типа Base свойство по-прежнему можно читать и изменять. Подкласс изменил внутреннее поведение setter, но не устранил саму операцию записи.

Для read-only-свойства базового класса допустимо добавить setter в переопределении. Это расширяет возможности подкласса, однако код, видящий объект как Base, всё равно будет использовать только гарантированный базовым классом getter.

Важно отличать переопределение от добавления нового свойства. Нельзя объявить в подклассе независимое хранимое свойство с тем же именем вместо корректного override. Для унаследованного свойства требуется явно переопределить его, а вычисляемое переопределение должно соответствовать требованиям базового контракта.

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

В базовом классе Document свойство status можно менять, поскольку workflow обновляет состояние документа. Подкласс PublishedDocument хочет запретить такие изменения и пытается переопределить status только getter-ом.

Вариант с read-only override не компилируется: функция, принимающая Document, всё ещё имеет право изменить status, а для PublishedDocument такая операция оказалась бы недоступной. Вариант с setter, который отклоняет недопустимое значение, сохраняет форму контракта, но может быть неудобен, если ошибка должна обрабатываться явно.

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

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

Разрешено ли переопределить read-only-свойство базового класса, добавив setter?

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

Почему нельзя оставить setter у базового свойства, но сделать его фактически нерабочим в подклассе?

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

Можно ли вместо переопределения добавить в подкласс одноимённое хранимое свойство?

Нет, это не создаёт корректную замену унаследованному свойству. Унаследованный член с тем же именем должен быть явно переопределён, а хранимое свойство нельзя произвольно подменить другим хранимым свойством в подклассе. Обычно используют вычисляемое свойство, делегирующее работу super, либо переопределяют унаследованное свойство с наблюдателями, если требуется только реагировать на изменения.