<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 25, 2016, at 11:49 AM, 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: Palatino-Roman; font-size: 14px; font-style: normal; font-variant-caps: 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=""><br class="Apple-interchange-newline">On Apr 25, 2016, at 10:13 AM, Erica Sadun <<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 25, 2016, at 10:49 AM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:</div><div class=""><div class="" style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant-caps: 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="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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></blockquote><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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></div></blockquote><div class=""><br class=""></div><div class="">Fair enough point but one that doesn't really sway me enough to include a native keyword for an ObjC compatibility feature.</div></div></div></div></blockquote><div class=""><br class=""></div>It’s a contextual keyword, so the impact is far less than a full-fledged keyword (but, point taken).</div></div></blockquote><div><br class=""></div>Ah, right. </div><div><br class=""><blockquote type="cite" class=""><div style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant-caps: 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=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class="" style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant-caps: 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=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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 class="" style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant-caps: 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;">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></blockquote><br class=""></div><div class="">And this is something I *did* overlook. Is there leeway to add labeled items `@objc(x: y)`? If so, `@objc(something)` could transition to `@objc(somelabel: something)` and a separate label be used for this.</div></div></div></blockquote><div class=""><br class=""></div><div class="">@objc(x: y) looks suspiciously like a typo for the selector @objc(x:y:).</div></div></blockquote><div><br class=""></div>Oh lord yes. Yes, it does. *headdesk*.</div><div><br class=""><blockquote type="cite" class=""><div style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant-caps: 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=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">The key point I want to make is that something that is semantically and syntactically external to the language should enter through a well regulated gateway.</div></div></div></blockquote><div class=""><br class=""></div><div class="">It’s not semantically and syntactically external. It is a real feature with specific, unique type-checking behavior. It is externally-motivated, and limited to interoperability with another language, but that doesn’t make it an external feature in the way that (say) some other tool that generates Swift code is external.</div></div></blockquote><div><br class=""></div></div>I think I made my points at least in terms of objc optional requirements though: <div class=""><br class=""></div><div class="">1. I think it's a very good thing. </div><div class="">2. I wish there were a better way to express it.<div class=""><br class=""></div><div class="">-- E, cc'ing in Chris who I believe *is* the review manager for SE-0070</div><div class=""><br class=""></div></div></body></html>