<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>To be fair, the "spirit of UIKit" that you mention comes from a time and language that encouraged OO and OO alone. Optional methods are, more often than not, backed by gigantic bit fields that keep track of whether or not the delegate actually conforms to the entirety of a protocol, which opens up a huge vector for bugs and complicates the internal logic of the control. <span style="background-color: rgba(255, 255, 255, 0);">I think Swift gives us a better opportunity to rethink the old approach not encourage it, don't you think?</span></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">For example, using a method returning an optional (or even better, a proper value) means you can give a proper semantics for what it means to not implement a particular method rather than "no selector here". <br><br>~Robert Widmann</div><div><br>2016/03/31 14:49、Yuval Tal via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><div dir="ltr">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. </div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 31, 2016 at 2:23 PM, Dave Abrahams via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
on Wed Mar 30 2016, Yuval Tal <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> I find that optional protocol methods to be very useful. However,<br>
> there is a caveat -- it needs to be mapped to @objc. This puts a set<br>
> of limitations, such as: structures cannot be used as parameters as it<br>
> does not map to objective-c. What do you think about removing the<br>
> requirement of using @objc and allow to create optional methods<br>
> without these limitations?<br>
<br>
</span>Caveat: this is going to be strongly-worded; sorry in advance. I think<br>
(no offense intended) it's a terrible idea. The whole notion of an<br>
“optional requirement” is nonsensical to begin with, and the use of<br>
optional protocol requirements encourages a style of programming that<br>
lifts the responsibility of the protocol designer for careful design at<br>
the expense of clients of the protocol. There are better ways to do<br>
things; let's not propagate this anti-pattern any further than it's<br>
already gone.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Dave<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>