<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPhone</div><div><br>On Mar 4, 2016, at 1:24 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 4, 2016, at 10:49 AM, John McCall 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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class="">On Mar 4, 2016, at 10:09 AM, Shawn Erickson via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><div class=""><div class="" style="white-space: pre-wrap;">(Sorry I hate top posting but fighting with Google inbox to avoid it)<br class=""><br class="">In delegation patterns it can be very helpful in terms of optimization (performance and memory) if the delegator can interrogate a delegate to know if certain delegation points are needed or not. I have code that has done this interrogation at delegate registration allowing potentially complex code paths and/or state maintenance to be avoided. It also could do impl caching to improve dispatch (did not support after registration "reconfiguring" delegates in this model purposely).<br class=""><br class="">Under objective-c leveraging optional protocol methods and runtime checks for responds to those was one built-in way for that. It also could add boilerplate code to check before dispatch that was potentially error prone and cumbersome. ...hence why I often did the check and configuration at registration in my code often avoiding peppering code with dispatch checks.<br class=""><br class="">Anyway not attempting to state anything for against this question about optional requirements in swift protocols. ...a handful of reasonable patterns exist in swift that allows one to achieve the same thing in safer and likely more performant ways.<br class=""></div></div></blockquote><div class=""><br class=""></div>Folks, this is obviously a language design discussion. Please do this sort of thing on swift-evolution. I’ve moved swift-dev to BCC.</div></div></blockquote><br class=""></div><div>Even without language support, you can model optional protocol conformances as optional property requirements, with pretty much the exact same behavior on the user side that we give officially optional requirements:</div><div><br class=""></div><div>protocol OptionalMethod {</div><div> var optionalMethod: Optional<() -> ()> { get }</div><div>}</div></div></blockquote><div><br></div><div>One issue with this modeling is argument labels. You can't really have a bunch of properties name "tableView". </div><div><br></div><br><blockquote type="cite"><div><div class="">-Joe</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>