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

[Sean Heber]

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
}

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.)

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