[swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Thorsten Seitz]

> Am 31.03.2016 um 17:18 schrieb Sean Heber <sean at fifthace.com>:
> 
> Some ideas I was thinking about for optional protocol functions was you’d declare it like this:
> 
> protocol UIGestureRecognizerDelegate {
>  optional func gestureRecognizerShouldBegin(gestureRecognizer: UIGestureRecognizer) -> Bool = true
> }


Why not just the following

import Foundation

// optional delegate method

protocol UIGestureRecognizerDelegate {
    var gestureRecognizerShouldBegin: ((gestureRecognizer: UIGestureRecognizer) -> Bool)? { get }
}

extension UIGestureRecognizerDelegate {
    var gestureRecognizerShouldBegin: ((gestureRecognizer: UIGestureRecognizer) -> Bool)? {
        return nil
    }
}


class UIGestureRecognizer {
    
    var delegate: UIGestureRecognizerDelegate?
    
    func callDelegate() {
        if let gestureRecognizerShouldBegin = delegate?.gestureRecognizerShouldBegin {
            gestureRecognizerShouldBegin(gestureRecognizer: self)
        }
    }
}


// implementing a delegate:

struct MyDelegate : UIGestureRecognizerDelegate {
    var gestureRecognizerShouldBegin: ((gestureRecognizer: UIGestureRecognizer) -> Bool)? {
        return { (gestureRecognizer: UIGestureRecognizer) -> Bool in
            return true
        }
    }
}

struct MyOtherDelegate : UIGestureRecognizerDelegate { }

This captures the idea of optional methods as used in Objective-C quite nicely IMO. And it already works without needing a new language feature.
If/when Swift gains the ability to declare default implementations within a protocol instead of needing an extension the boilerplate of having to repeat everything in the extension would drop away.


> If you put “optional” there, the compiler would auto-generate an empty function in a protocol extension in your module as if you had specified one yourself. If the function has a return value, you would be required to specify the default return value in the protocol which provides automatic documentation of the default, too. (It would be an error to have an optional function with a return value that doesn’t have a default value specified in the protocol.) (I am not currently in favor of supplying a default implementation body inside of a protocol as has been discussed some previously.)

I do not understand why an optional method should require a default value. That’s not how optional methods work in Objective-C where the caller will ask whether the method is implemented and calls it or does something else. With a default value it would be much more difficult to do something different if the method is not implemented.
Actually with a default value the method would just be a normal method which has not been overridden, there would be nothing optional about it anymore.

-Thorsten


> 
> If you provide a default implementation of an optional protocol function in a protocol extension in the same module as the protocol itself is declared in, it would be an error and you’d have to make the function non-optional or get rid of your conflicting protocol extension implementation. If the protocol was declared in a different module, then that restriction would be lifted since presumably you’re providing a default implementation via protocol extension on purpose.
> 
> l8r
> Sean
> 
> 
>> On Mar 31, 2016, at 1:34 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Just a thought: optional methods could be modeled by methods in a protocol that return optional closures.
>> 
>> -Thorsten
>> 
>> 
>> Am 31. März 2016 um 04:42 schrieb Andrey Tarantsov via swift-evolution <swift-evolution at swift.org>:
>> 
>>> I'm missing those optional methods too, but protocol extensions sound like a better solution for this.
>>> 
>>> (For those suggesting a separate protocol, consider UITableView. How many protocols would it take to model all the optional delegate methods as separate protocols? Certainly more than 10, perhaps a few dozen.)
>>> 
>>> I would welcome a standardized way to document the methods as optional-to-implement, though, beyond just requiring a protocol extension. My ideal option would be to allow the optional keyword and change it to simply require a default implementation in a protocol extension.
>>> 
>>> If we don't want a language change, then perhaps a conventional doc tag?
>>> 
>>> A.
>>> 
>>> 
>>>> On Mar 30, 2016, at 8:08 PM, Yuval Tal via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I find that optional protocol methods to be very useful. However, there is a caveat -- it needs to be mapped to @objc. This puts a set of limitations, such as: structures cannot be used as parameters as it does not map to objective-c. What do you think about removing the requirement of using @objc and allow to create optional methods without these limitations?
>>>> 
>>>> Thank you,
>>>> 
>>>> -Yuval
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160331/826c1656/attachment.html>