<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 31, 2016, at 11:49 AM, Yuval Tal via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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></blockquote><div><br class=""></div><div>Protocol requirements with default (no-op) implementations already satisfy that design goal, no?</div><div><br class=""></div><div>-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Mar 31, 2016 at 2:23 PM, Dave Abrahams via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
on Wed Mar 30 2016, Yuval Tal <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
<br class="">
> Hi,<br class="">
><br class="">
> I find that optional protocol methods to be very useful. However,<br class="">
> there is a caveat -- it needs to be mapped to @objc. This puts a set<br class="">
> of limitations, such as: structures cannot be used as parameters as it<br class="">
> does not map to objective-c. What do you think about removing the<br class="">
> requirement of using @objc and allow to create optional methods<br class="">
> without these limitations?<br class="">
<br class="">
</span>Caveat: this is going to be strongly-worded; sorry in advance. I think<br class="">
(no offense intended) it's a terrible idea. The whole notion of an<br class="">
“optional requirement” is nonsensical to begin with, and the use of<br class="">
optional protocol requirements encourages a style of programming that<br class="">
lifts the responsibility of the protocol designer for careful design at<br class="">
the expense of clients of the protocol. There are better ways to do<br class="">
things; let's not propagate this anti-pattern any further than it's<br class="">
already gone.<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
--<br class="">
Dave<br class="">
</font></span><div class="HOEnZb"><div class="h5"><br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>