<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>We could require optional methods which would return T to instead return OptionalResult<T> which is essentially an enum with values 'unimplemented' and 'implemented(T)', i.e. essentially the same as Optional but as a separate type to avoid confusion when the real result would be 'T?'.</div><div><br></div><div>Default implementations would answer 'unimplemented'.</div><div><br></div><div>This would require the caller to handle the unimplemented default case explicitly.</div><div><br></div><div>-Thorsten </div><div><br></div><div><br>Am 22.04.2016 um 02:58 schrieb David Waite via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<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 Apr 21, 2016, at 9:58 AM, Alex Martini via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div></blockquote><br class=""><blockquote type="cite" class=""><div class=""><span style="color: rgb(12, 55, 98); font-size: 1.1em; font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">What to do about optional requirements</span></div></blockquote><br class=""><blockquote type="cite" class=""><div class=""><a class="external reference" href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/14046" style="text-align: justify; font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; font-weight: bold; text-decoration: none; color: rgb(137, 38, 1);">http://thread.gmane.org/gmane.comp.lang.swift.evolution/14046</a></div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="section" id="what-to-do-about-optional-requirements" style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;"><ol class="arabic simple" style="padding-left: 20px; list-style-position: initial; list-style-image: initial;"><li style="line-height: 1.3;" class="">Rename it to make it clearly an Objective-C interop feature. We could also forbid you actually spelling it in Swift code. That doesn’t work well because it breaks your ability to write code in Swift that has Objective-C clients — those clients won’t get the default implementation from the extensions like you would use with Swift clients instead of creating optional requirements.</li><li style="line-height: 1.3;" class="">Modeling optional requirements as a function of optional type such as <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">((A,</span> <span class="pre">B)</span> <span class="pre">-></span> <span class="pre">C)?</span></tt> doesn’t work well. For example, properties can have optional type and they can be optional requirements, so you would end up having to deal with a lot of extra complexity due to double-optionals and likely want better code completion so you could type it all out.</li><li style="line-height: 1.3;" class="">You force the default implementation to be visible from all callers, and you do the dispatch at the call site. The only advantage of this is that it takes optional requirements out of the language entirely. If you wanted to implement the (somewhat common) pattern of checking whether a type implements an optional requirement, you would have to use a <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">respondsToSelector</span></tt> check.</li></ol></div></div></div></div></blockquote>Calling an optional method on a delegate protocol and using the result to judge whether you should have some default behavior to me does seem a bit flimsy in retrospect (I originally proposed things like importing optional methods with throws and having an unimplemented method error raised by default, etc). You aren’t really trying to judge that the behavior ‘currently’ is the default, but that there is no behavior defined thus you can reliably *always* use the default.</div><div><br class=""></div><div>To that end, you need some way to detect static features of a type at runtime. Today we have respondsToSelector for objc types, and checking for conformance to different protocols.</div><div><br class=""></div><div>I don’t think supporting optional protocols in swift could work unless there was also a respondsToSelector equivalent for native swift types.</div><div><br class=""></div><div>-DW</div><br class=""></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>