> Am 31.03.2016 um 17:18 schrieb Sean Heber <s...@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@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

Reply via email to