Native Optional Methods in Swift Protocols

[KaiTheBuilder (Kai Tay)]

There are a LOT of prior suggestions similar to this:

• https://forums.swift.org/t/is-there-an-underlying-reason-why-optional-protocol-requirements-need-objc
• https://forums.swift.org/t/idea-how-to-eliminate-optional-protocol-requirements
• https://forums.swift.org/t/proposal-draft-remove-objc-requirement-for-optional-protocol-methods-properties
• https://forums.swift.org/t/review-se-0070-make-optional-requirements-objective-c-only
• https://forums.swift.org/t/proposal-make-optional-protocol-methods-first-class-citizens
• Optional Protocol Members

In particular, this was the SE to get rid of optional requirements in Swift (it was once a thing, very very very early on). However, I can't find the rationale behind not wanting "optional requirements" (funny name) in Swift Protocols - I only see it being stated. The SE forums thread was also rather sparse, so I'm not sure if I'm missing something.

=====

I'm personally in favour of optional methods. I have a lot of delegate-style protocols in my apps, which usually look like:

protocol CatDelegate {
    func catDidSit(_ cat: Cat)
    func catDidStand(_ cat: Cat)
    func catDidEat(_ cat: Cat)
}

protocol CatDelegate {
    /* default implementations, it's just {} for each case */
}

class CatFoodTracker: CatDelegate {
    func catDidEat(_ cat: Cat) {
        print("CAT ATE FOOD")
    }
}

However, the default implementations are a bit of a pain when I need to refer to the original functions in docc (since they have the same name and signature), and honestly just having those functions be optional would be fine. We can just

• Bring back the optional keyword
• Call functions using objectConformingToProtocol.myMethod?() (we use this syntax already for objc optional methods and optional closures)
• Remove a default implementation by func myMethod?() = nil or smth like that