<div dir="ltr"><div>I'm on the fence here, I think it's a good solution if a project has ongoing objc dependencies.</div><div><br></div><div>However I have a few issues/suggestions:</div><div><br></div><div>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><br></div><div>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></div><div><br></div><div>3) If this proposal went ahead would existing code be migrated to add the annotation everywhere? (to retain equivalence)</div><div><br></div><div>4) Have you explored any alternatives?</div><div> * instead of defaulting to @objc require an explicit @objc or @nonobjc, otherwise have a compile-time warning; default to @nonobjc still (for consistency).<br></div><div> * @objc(inherit=false)</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>when put on the protocol it disables what you propose, inherit is true by default.</div></blockquote><div> * compile time feedback:</div><div> + 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"><div>This may only work in whole module optimisation, also the dynamic nature of objc may prevent it from being deterministic.</div></blockquote><div> + 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"><div>If I remember correctly something like this may already exist.</div></blockquote><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 5, 2016 at 4:02 PM, Douglas Gregor via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Jan 4, 2016, at 8:58 PM, John Joyce <<a href="mailto:uchuugaka@icloud.com" target="_blank">uchuugaka@icloud.com</a>> wrote:</div><br><div><div style="word-wrap:break-word">Would it not be possible to do the relative analog of Objective-C nullability macro sandwiches in Swift?<div>And then allowing exceptions within the file to be called out explicitly with @nonobjc or @objc ?<br><div>@begin_assume_nonobjc</div><div>@end_assume_nonobjc</div><div>@begin_assume_objc</div><div>@begin_assume_objc<br></div></div></div></div></blockquote><div><br></div></span><div>Ick :)</div><div><br></div><div>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><br></div><span style="white-space:pre-wrap">        </span>- Doug</div><div><div class="h5"><div><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><div><div><blockquote type="cite"><div>On Jan 5, 2016, at 1:54 PM, Kevin Lundberg via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><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:normal;word-spacing:0px;float:none;display:inline!important">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"><span style="white-space:pre-wrap">        </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"><span style="white-space:pre-wrap">        </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"><span style="white-space:pre-wrap">        </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"><span style="white-space:pre-wrap">        </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"><span style="white-space:pre-wrap">                </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"><span style="white-space:pre-wrap">                </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">                </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">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"><span style="white-space:pre-wrap">                </span>func blah() { }<span style="white-space:pre-wrap">                </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"><span style="white-space:pre-wrap">                </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"><span style="white-space:pre-wrap">        </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"><br></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">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"><div><br></div><br><div><blockquote type="cite"><div>On Jan 4, 2016, at 11:32 PM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word">Hi all,<div><br></div><div>We currently have a bit of a surprise when one extends an @objc protocol:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>@objc protocol P { }</div></div><div><div><br></div></div><div><div>extension P {</div></div><div><div> func bar() { }</div></div><div><div>}</div></div><div><div><br></div></div><div><div>class C : NSObject { }</div></div><div><div><br></div></div><div><div>let c = C()</div></div><div><div>print(c.respondsToSelector("bar")) // prints "false"</div></div></blockquote><div><br></div><div>because the members of the extension are not exposed to the Objective-C runtime. </div><div><br></div><div>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><br></div><div>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><br></div><div><span style="white-space:pre-wrap">        </span>- Doug</div><div><br></div><div>[*] 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"></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></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"><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"><span> </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"><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">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"><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">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"><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">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br></div></div></div></div></blockquote></div><br>
<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">
</div></div></div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>