<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 Apr 24, 2016, at 7:02 PM, Erica Sadun <<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 24, 2016, at 3:28 PM, Chris Lattner 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=""><br class=""><blockquote type="cite" class="">On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class=""><br class="">Sent from my iPhone<br class=""><br class=""><blockquote type="cite" class="">On Apr 22, 2016, at 5:56 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:<br class=""><br class="">Not an expert on Obj-C compatibility in Swift by any means, but this<br class="">reads like it's largely a change of nomenclature. To me, though,<br class="">`objcoptional` reads exceedingly poorly. Why not emphasize the Obj-C<br class="">compatibility angle by requiring the `@objc` attribute to precede each<br class="">use of `optional`? (In other words, effectively rename `optional` to<br class="">`@objc optional`.)<br class=""></blockquote><br class="">That is a great idea. <br class=""></blockquote><br class="">Doesn’t this have the same problem as the current (Swift 1/2) implementation? People will continue to believe that it is a bug that you must specify @objc.<br class=""><br class="">-Chris<br class=""></div></div></blockquote><br class=""></div><div class="">I thought I'd throw a few ideas into the mix. I'm arriving late to the discussion. (I didn't expect the conversation to last this long.) I did take a quick look back through the thread but I may have missed some bits along the way. Apologies in advance for any redundancy:</div></div></div></blockquote><div><br class=""></div><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">* Swift's "optional" protocol implementations are no such thing. They are default implementations that can be overridden.</div></div></blockquote><div><br class=""></div><div class="">(Pulling this one out first). When I read “a default implementation that can be overridden”, I think of the conforming type *or a subclass thereof* providing a different implementation from the default. “Optional” requirements are things that the conforming type does not have to provide…. and a user of the protocol must cope with conforming types that don’t provide them.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""> (Tangentially, why not introduce a required "override" keyword for conforming types that implement a version of a member introduced in protocol extensions? This would match the class approach and enhance safety and intent.)</div></div></blockquote><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">This is a commonly-requested feature that I don’t think we need. The TL;DR version is that I feel like specifying the conformance explicitly (my type Foo conforms to protocol P) already expresses intent, and the compiler should help with the rest. I’ve recently been working on providing better warnings for cases where one has tried to implement an optional requirement for a protocol (but got the declaration wrong), and I think we can turn it on for cases where one got a default implementation instead:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://thread.gmane.org/gmane.comp.lang.swift.devel/1799" class="">http://thread.gmane.org/gmane.comp.lang.swift.devel/1799</a></div><div class=""><br class=""></div></div></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">* Optional requirement is an oxymoron. (This is a redux of my previous contribution to this topic but it's a good starting point.)</div><div class=""><br class=""></div><div class="">* Swift already has an `Optional` type. Importing ObjC "optional" protocol requirements is therefore semantically problematic from a Swift development POV. I don't like either the "@objcoptional" or "@objc optional" solutions mentioned upthread. They overload "optional" syntactically and confuse semantics. I think the key words that better describe what's happening in, for example, a `UITableViewDelegate`, are "<i class="">discretionary</i>" or "<i class="">elective</i>" implementations. Swift has renamed lots of Objective C things (waves hi to <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md" class="">SE-0005</a>). Why not "optional”?</div></div></div></blockquote><div><br class=""></div><div>If we were adding optional requirements to Swift protocols, I would agree that it makes sense to change the nomenclature to avoid the oxymoron and the confusion with optionals. However, since this is now moving into the realm of “Objective-C compatibility feature”, I think it’s reasonable to retain the existing, Objective-C terminology.</div><div><br class=""></div><div>Also, there is a link between the Optional type and optional requirements: when you reference an optional requirement, you get back an Optional.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">* I do *support* retaining `@objc` in some form and I believe it can be addressed in a way that does not appear to be a bug. "Optional protocol conformance" is a behavior that is external to the language. I do not believe would be voluntarily added to Swift should the topic arise. </div></div></div></blockquote><div><br class=""></div><div>It’s a feature that exists to support compatibility with another language; we would not add it if it not for Objective-C. However, it is a real language feature with different semantics from other language features.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Therefore I find it insufficient to introduce attributes like `@elective` or `@discretionary` in order to satisfy non-native requirements. I would prefer to see the @objc attribute be extended to support these and any future Objective-C-specific behaviors: @objc(elective), @objc(importedProtocolSupport: elective), or whatever. While these are wordy, I assume like any other Swift attributes they can be placed on a line before the function declaration, and it would be instantly clear why they've been placed there, and they would not overlap with Swift semantics *or* expectations. I leave the color of the bikeshed as an exercise for the reader.</div></div></div></blockquote><br class=""></div><div>Do remember that @objc(something) already has a meaning: it gives the Objective-C name “something” to the entity that the @objc(something) describes.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""></div><br class=""></body></html>