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@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@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@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@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
