<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 Jan 5, 2016, at 3:40 AM, Andrew Bennett <<a href="mailto:cacoyi@gmail.com" class="">cacoyi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">I'm on the fence here, I think it's a good solution if a project has ongoing objc dependencies.</div></div></div></blockquote><div><br class=""></div><div>If the Objective-C runtime is there, you have ongoing Objective-C dependencies: we call them Cocoa and Cocoa Touch ;)</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">However I have a few issues/suggestions:</div><div class=""><br class=""></div><div class="">1) If a project is iteratively migrating from objc to swift, as I'm sure many are (a large project I'm working on included), then it would make that job much more tedious and increase the objc footprint in the swift code.</div></div></div></blockquote><div><br class=""></div><div>I don’t know what you mean by this. Your Objective-C code doesn’t contain protocol extensions, and the incremental cost to writing @nonobjc for members of extensions of @objc protocols (or accepting the Fix-It) is trivial.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">2) A linter could help me slowly remove unnecessary side-effects of this proposal, but it's not ideal, and it does not solve the large amounts of annotations needed to do so.<br class=""></div></div></div></blockquote><div><br class=""></div><div>You’re worried about migrating an @objc protocol to a non-@objc protocol, and it has so many protocol extensions that the cost of removing the @nonobjc (or accept the Fix-It) is prohibitive? That seems very, very unlikely to me.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">3) If this proposal went ahead would existing code be migrated to add the annotation everywhere? (to retain equivalence)</div></div></div></blockquote><div><br class=""></div><div>Yes, where “everywhere” == “extensions of @objc protocols”.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">4) Have you explored any alternatives?</div><div class=""> * instead of defaulting to @objc require an explicit @objc or @nonobjc, otherwise have a compile-time warning; default to @nonobjc still (for consistency).<br class=""></div><div class=""> * @objc(inherit=false)</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class="">when put on the protocol it disables what you propose, inherit is true by default.</div></blockquote><div class=""> * compile time feedback:</div><div class=""> + An objc compile time warning/error suggesting you add @objc if there's no matching selector, but there is a swift method.</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class="">This may only work in whole module optimisation, also the dynamic nature of objc may prevent it from being deterministic.</div></blockquote><div class=""> + A swift compile time warning/error suggesting you add @objc if there's an objc protocol and an unannotated swift implementation.</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class="">If I remember correctly something like this may already exist.</div></blockquote></div></div></blockquote><div><br class=""></div><div>The idea of eliminating the blanket @objc default in subclasses of Objective-C-defined classes has come up. It would require us to infer ‘@objc’ in more places (and you noted), and would obviate the need for my proposal because the expectation of @objc-by-default would go away. That is a *much* larger and more interesting discussion.</div><div><br class=""></div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Jan 5, 2016 at 4:02 PM, Douglas Gregor via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jan 4, 2016, at 8:58 PM, John Joyce <<a href="mailto:uchuugaka@icloud.com" target="_blank" class="">uchuugaka@icloud.com</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class="">Would it not be possible to do the relative analog of Objective-C nullability macro sandwiches in Swift?<div class="">And then allowing exceptions within the file to be called out explicitly with @nonobjc or @objc ?<br class=""><div class="">@begin_assume_nonobjc</div><div class="">@end_assume_nonobjc</div><div class="">@begin_assume_objc</div><div class="">@begin_assume_objc<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Ick :)</div><div class=""><br class=""></div><div class="">If we need to annotate several things at once, doing it an extension granularity is good enough, because there’s essentially no cost to merging or breaking apart extensions as needed.</div><div class=""><br class=""></div><span style="white-space:pre-wrap" class=""> </span>- Doug</div><div class=""><div class="h5"><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 5, 2016, at 1:54 PM, Kevin Lundberg via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">I like this idea, but I would imagine that for an extension with many functions in it, requiring @nonobjc on each one would get tedious very fast. Could it be required (or at least allowed in addition to per-method annotations) at the extension level?:</span><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="white-space:pre-wrap" class=""> </span></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="white-space:pre-wrap" class=""> </span>@objc protocol P {}</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="white-space:pre-wrap" class=""> </span></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="white-space:pre-wrap" class=""> </span>@nonobjc extension P {</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="white-space:pre-wrap" class=""> </span>func foo() { }</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="white-space:pre-wrap" class=""> </span>func bar() { }</div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px" class=""> </span><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">func baz() { }</span><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="white-space:pre-wrap" class=""> </span>func blah() { }<span style="white-space:pre-wrap" class=""> </span></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="white-space:pre-wrap" class=""> </span>// etc...</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="white-space:pre-wrap" class=""> </span>}</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing: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;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">I don’t know if this would have specific implementation ramifications over only doing this on each method, if extensions cannot already be modified with attributes. I can’t think of a case where I’ve seen annotations added to protocol extensions, or any other extensions for that matter.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 4, 2016, at 11:32 PM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class="">Hi all,<div class=""><br class=""></div><div class="">We currently have a bit of a surprise when one extends an @objc protocol:</div><div class=""><br class=""></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class=""><div class="">@objc protocol P { }</div></div><div class=""><div class=""><br class=""></div></div><div class=""><div class="">extension P {</div></div><div class=""><div class=""> func bar() { }</div></div><div class=""><div class="">}</div></div><div class=""><div class=""><br class=""></div></div><div class=""><div class="">class C : NSObject { }</div></div><div class=""><div class=""><br class=""></div></div><div class=""><div class="">let c = C()</div></div><div class=""><div class="">print(c.respondsToSelector("bar")) // prints "false"</div></div></blockquote><div class=""><br class=""></div><div class="">because the members of the extension are not exposed to the Objective-C runtime. </div><div class=""><br class=""></div><div class="">There is no direct way to implement Objective-C entry points for protocol extensions. One would effectively have to install a category on every Objective-C root class [*] with the default implementation or somehow intercept all of the operations that might involve that selector. </div><div class=""><br class=""></div><div class="">Alternately, and more simply, we could require @nonobjc on members of @objc protocol extensions, as an explicit indicator that the member is not exposed to Objective-C. It’ll eliminate surprise and, should we ever find both the mechanism and motivation to make default implementations of @objc protocol extension members work, we could easily remove the restriction at that time.</div><div class=""><br class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span>- Doug</div><div class=""><br class=""></div><div class="">[*] Assuming you can enumerate them, although NSObject and the hidden SwiftObject cover the 99%. Even so, that it’s correct either, because the root class itself might default such a method, and the category version would conflict with it, so...</div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=AxVqvhl7qaAz-2FE20TrrgNT-2F44XdgxmRgRA416dJII-2BQz5GMEwtrepqdUUfZBVgxzupW-2FPREoEcvPuC6wsAH1ZgTgZvIgx9Cm5p-2Fim2dRGZC3BzZSAr92XbNX9O-2Fflllcl5tPAb-2F2FNz46tzDkyElF81H5qSzxTONWvrYHwtxQPz5FcR-2BVMHI-2BNJ0-2BTyuxt-2B5AjsXMd78T4fzeyZGeK9GAujjENi69walodNo8ahVnBY-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0px!important;margin:0px!important;padding:0px!important" class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=1UuF0lDdi-2BUHzKWDs6hnDkbjNauJshI0mDryye6koZFsEeZT4CGHIq1WvkBe4BCqIMEEeREZZktIl4zGYUfWFUXrX9loSN2BKCeNDP-2BN8HWp9qYuk-2Fbz37YQ5TwZNGxzCReNLLbA0gAwgFSuoJH4ar-2F0DdB91QJbvgcR6B6xTAfgrofvFJ247mF-2Ba-2BIB4WZsjE9Jdt-2BV0fEfetDi7W4yr5M9qJNErNSP2z06Kl5IgnQ-3D" alt="" width="1" height="1" border="0" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;min-height:1px!important;width:1px!important;border-width:0px!important;margin:0px!important;padding:0px!important" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class=""><span class=""> </span>_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">swift-evolution mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><a href="mailto:swift-evolution@swift.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">swift-evolution@swift.org</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class="">
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=pQw7h83fWt3LLbgkfL4TSUL0weaZnVFZxDe5GShw4uRK8IfbQeFgO226fJvMQzmNgjvI3Db7HgqDD-2FVgM6qLNzL8D5h-2FbphaD-2BmqrM3QeDg5hxBIHM7zCG3m4kuSrjuu5G471HwTyPUG4qUVswxaG6t5NKhfgdKRMmtvP0ja44EZRGWSWsk-2Fyh8VDm6IKGjG4-2Fp0uEY7kEj5-2BcK-2FCidMJA6xW533TUDvMyj1W1A-2F8U4-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important" class="">
</div></div></div>
<br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>