None taken. However, most of the delegate concept of UIKit relies heavily on this "nonsensical" requirement. It is impossible for someone to implement a control in swift which is "in the spirit" of UIKit, meaning the control has a delegate, with several methods that share the same name with different parameters, some are required and some are optional. I think it is not fair to tell users that they cannot implement something that is such a common and repeating pattern in the core.
On Thu, Mar 31, 2016 at 2:23 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Wed Mar 30 2016, Yuval Tal <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? > > Caveat: this is going to be strongly-worded; sorry in advance. I think > (no offense intended) it's a terrible idea. The whole notion of an > “optional requirement” is nonsensical to begin with, and the use of > optional protocol requirements encourages a style of programming that > lifts the responsibility of the protocol designer for careful design at > the expense of clients of the protocol. There are better ways to do > things; let's not propagate this anti-pattern any further than it's > already gone. > > -- > Dave > > _______________________________________________ > 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
