[swift-evolution] Will Swift ever support optional methods without @objc?

Karl razielim at gmail.com
Wed Nov 16 08:52:01 CST 2016

> On 16 Nov 2016, at 05:25, Shawn Erickson <shawnce at gmail.com> wrote:
> Again my point isn't worrying about point of calling out to the delegate but configuring my delegator to avoid a body of work or state management that is unneeded if the delegate doesn't care about some mix of potential delegation points. I was trying to point out things to consider for those stating "why not just provide a default implementation that is a nop, etc." when in fact knowing if the delegate decided to not implement something can be helpful for some delegators. 
> Anyway as stated earlier sub protocols likely are good enough however I am concerned about it degenerating into a single func per sub protocol in not atypical situations.
> -Shawn 

Even if it does just become a single method, it’s not a cause for concern. In the example before, we gave some semantic meaning to those bundles of optional methods, so that’s a bit of a win. Also, what’s cool is that instead of the members being optional, the conformance to the sub-protocol is what is optional, and anything which declares conformance must implement all of the extra callbacks. The upshot of this is that the compiler is able to validate everything and produce an error if the extra callbacks change in the future.

For example:

class MyViewController : ScrollObserver { 
    func scrollViewDidScroll(_ scrollview: UIScrollView) {
        // handle scroll

Now we decide to change the function signature of this optional callback (for some reason. Let’s say we want to add a parameter…):

protocol ScrollObserver : ScrollViewDelegate {
    func scrollViewDidScroll(_ scrollview: UIScrollView, from lastLocation: CGPoint)

If the method was “optional”, objects would suddenly stop implementing this requirement and it would still be perfectly valid code. However, as a sub-protocol, we get proper validation and the compiler will produce an error until we update everything to handle the new signature.

I think this problem has actually come up with @obj-c protocols. Some signatures changed in Swift 3 due to API overlay improvements and some conformances silently failed to resolve, IIRC.

- Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161116/3368ad44/attachment.html>

More information about the swift-evolution mailing list