<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 4, 2016, at 8:32 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</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=""><br class=""><br class="">Sent from my iPhone</div><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=""><br class="">On Mar 4, 2016, at 1:24 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" 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=""><div class=""><br class=""><div class=""><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 class="" 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;"><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 class="">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 class=""><br class=""></div><div class="">protocol OptionalMethod {</div><div class=""> var optionalMethod: Optional<() -> ()> { get }</div><div class="">}</div></div></blockquote><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=""><br class=""></div><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="">One issue with this modeling is argument labels. You can't really have a bunch of properties name "tableView". </div></div></blockquote><br class=""></div><div>We could conceivably allow for properties with closure types to have compound names. That would also benefit the optional binding `if let tableView(_:blah:) = delegate.tableView(_:blah:) { ... }`.</div><div><br class=""></div><div>-Joe</div><br class=""></body></html>