Что нарушает опциональную функцию в протоколе?

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

Опциональные требования позволяют расширять протоколы, не "ломая" существующие реализации. Классы или структры могут реализовывать только часть опциональных методов. Это полезно при работе с делегатами или при добавлении новых функций в уже устоявшийся API.

Пример опционального требования в протоколе на Objective-C (поскольку Swift не поддерживает @optional без @objc):

// В Swift @optional используется с @objc protocol
import Foundation

@objc protocol MyDelegate {
    func requiredMethod() -> Bool

    @optional func optionalMethod1()
    @optional func optionalMethod2(value: Int)
}

class MyClass {
    weak var delegate: MyDelegate?

    func doSomething() {
        if delegate?.requiredMethod() == true {
            // Вызываем опциональный метод с проверкой
            delegate?.optionalMethod1?()

            if let delegate = delegate {
                if delegate.responds(to: #selector(delegate.optionalMethod2(value:))) {
                    delegate.optionalMethod2?(value: 10)
                }
            }
        }
    }
}

В Swift чистые протоколы (без @objc) не поддерживают @optional. Чтобы иметь опциональные требования, протокол должен быть помечен как @objc. Реализации таких протоколов могут использовать расширения для добавления реализаций опциональных методов по умолчанию, что является более современным подходом в Swift.

Пример опционального поведения через расширения протоколов в Swift:

// Более Swift-овый подход: расширения протоколов с реализацией по умолчанию
protocol MyProtocol {
    func requiredMethod() -> Bool
    func optionalMethod1()
    func optionalMethod2(value: Int)
}

// Предоставляем реализации по умолчанию для "опциональных" методов
extension MyProtocol {
    func optionalMethod1() {
        // Пустая реализация по умолчанию или какое-то стандартное поведение
        print("Optional method 1 default implementation")
    }

    func optionalMethod2(value: Int) {
        // Пустая реализация по умолчанию
        print("Optional method 2 default implementation with value: \(value)")
    }
}

class MyClassSwift {
    var delegate: MyProtocol?

    func doSomething() {
        if delegate?.requiredMethod() == true {
            // Вызываем методы без проверки на nil для optionalMethod, так как они 
            // либо реализованы в классе/структуре, либо используется 
            // реализация из расширения
            delegate?.optionalMethod1()
            delegate?.optionalMethod2(value: 20)
        }
    }
}

class MyCustomDelegate: MyProtocol {
    func requiredMethod() -> Bool {
        print("Required method implemented")
        return true
    }

    // optionalMethod1() и optionalMethod2(value:) не обязательно реализовывать, 
    // будет использоваться реализация по умолчанию из расширения.
    // Но можно переопределить их, если нужно другое поведение:
    // func optionalMethod1() {
    //     print("Custom implementation of optional method 1")
    // }
}

let customDelegate = MyCustomDelegate()
let myClassSwift = MyClassSwift()
myClassSwift.delegate = customDelegate
myClassSwift.doSomething()

Таким образом, нарушает опциональную функцию в протоколе попытка добавить новое обязательное требование к уже существующему протоколу, который используется в кодовой базе. Использование опциональных требований (через @objc или, предпочтительнее, через расширения протоколов) предотвращает это нарушение обратной совместимости.