<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 Mar 17, 2016, at 12:04 AM, Adrian Kashivskyy 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=""><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=""><div class="">I have a couple of ideas regarding the API of <font face="Menlo" class="">ObjectiveCBridgeable</font>. My general thought is to improve upon the existing <font face="Menlo" class="">_ObjectiveCBridgeable</font> protocol, not just make it public. The main idea would be to make it more "Swifty" by:</div><div class=""><div class=""><br class=""></div><div class="">1. Removing <font face="Menlo" class="">inout</font> arguments which look like implementation artifacts and converting them into return values</div></div></div></div></blockquote><div><br class=""></div><div>They are implementation artifacts, because these methods are called by C++ code in the runtime (for dynamic casting), and inout is *much* easier to work with because you know it’s always passed indirectly.</div><div><br class=""></div><div>One could almost clearly clean up the primary interface to make it more natural in Swift, then use defaulted implementations for the more runtime-friendly entrypoints.</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=""><div class="">2. Converting static functions to initializers</div></div></div></div></blockquote><div><br class=""></div><div>Yes, that’s reasonable, but see the above.</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=""><div class="">3. Removing<font face="Menlo" class=""> isBridgedToObjectiveC()</font> method since it doesn't introduce any useful information</div></div></div></div></blockquote><div><br class=""></div></div><div class="">It tells us, dynamically, whether the bridging is actually possible, and is used by the runtime. For example:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Menlo" class="">func foo<T>(foo: Array<T>) {</font></div><div class=""><font face="Menlo" class=""> if let obj = foo as? NSArray {</font></div><div class=""><font face="Menlo" class=""> // whether we get here depends on T, dynamically</font></div><div class=""><font face="Menlo" class=""> }</font></div><div class=""><font face="Menlo" class="">}</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""><div class="">struct SomeStruct { }</div><div class=""><br class=""></div><div class="">foo([SomeStruct]()) // “Not bridged"</div><div class="">foo([String]()) // “Bridged"</div></font></div></blockquote><div class=""><br class=""></div><div class="">If you look at the implementation of Array’s conformance to _ObjectiveCBridgeable, for example, it dynamically checks whether its element type is _ObjectiveCBridgeable.</div><div class=""><br class=""></div><div class="">Note that isBridgedToObjectiveC is a hack because we don’t have conditional conformances, i.e., we can’t say that Array<T> conforms to _ObjectiveCBridgeable when T is representable in Objective-C. That’s obviously not something to be fixed by this proposal, but hopefully it helps illustrate why isBridgedToObjectiveC matters.</div><div class=""><br class=""></div><div class="">Perhaps you and Russ can work together to clean up _ObjectiveCBridgeable within the proposal? I’ll have more comments on the proposal soon-ish.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div class=""><br class=""></div></body></html>