Ответ.

Protocol extensions были введены в Swift для поддержки идеологии protocol-oriented programming: программист может внедрить реализации методов по умолчанию непосредственно на уровне протокола, а не через базовый класс-предок или глобальные функции. Это уменьшает дублирование кода и позволяет гибко адаптировать поведение типов.

Проблема возникает тогда, когда default реализация маскирует необходимость собственной (override), или когда линия ответственности размывается — особенно, если тип реализует несколько протоколов с пересечениями. Кроме того, важно помнить: если реализован метод в самом типе, он всегда перекроет реализацию из extension.

Решение — использовать protocol extensions только для универсального поведения, а в отдельных случаях явно реализовывать метод внутри типа. Желательно избегать перегрузки одних и тех же методов в двух extension для одного протокола.

Пример кода:

protocol Flyer {
    func fly()
}
extension Flyer {
    func fly() {
        print("Default flying")
    }
}

struct Bird: Flyer {}
let sparrow = Bird()
sparrow.fly() // Выведет: Default flying

Ключевые особенности:

Позволяют предоставлять общий функционал и уменьшать дублирование без inheritance.
Реализация по умолчанию работает только если тип явно не определил свой метод.
Позволяют использовать generic и where constraints для уточнения поведения для определённых типов.

Вопросы с подвохом.

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

Нет, только вычисляемые свойства и методы могут быть добавлены в protocol extensions. Хранимые свойства запрещены.

Что произойдет, если у протокола и у типа есть разные реализации метода с одним именем? Какой вызовется?

При прямом обращении к типу вызовется реализация типа, при обращении к экземпляру через ссылку типа протокола — реализация protocol extension.

protocol Greeter {
    func greet()
}
extension Greeter {
    func greet() { print("Hi from extension") }
}
struct Person: Greeter {
    func greet() { print("Hi from type") }
}

let person = Person()
person.greet()            // Hi from type
let greeter: Greeter = person
greeter.greet()           // Hi from extension

**Можно ли в protocol extension использовать where constraints для ограничений? **

Да. Это одна из мощных возможностей — протокол можно расширять только для определённых типов.

extension Collection where Element: Equatable {
    func allEqual() -> Bool {
        guard let first = self.first else { return true }
        return allSatisfy { $0 == first }
    }
}

Типовые ошибки и анти-паттерны

Реализация поведения с помощью protocol extension, ожидая override в конкретных типах: protocol extension не поддерживает override, это не класс.
Перекрытие метода типа и метода extension (разные сигнатуры или бизнес-логика) может привести к неожиданному полиморфному поведению.

Пример из жизни

** Негативный кейс

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

Плюсы:

Мало кода, легко поддерживать базовую реализацию.

Минусы:

Сюрпризы при runtime-полиморфизме, расхождение намерения и выполнения, баги на production.

** Позитивный кейс

Протокол расширяют только для тех случаев, где поведение всегда универсально. Для особых случаев — явная реализация методов в типе, есть code review на конфликтные места.