<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=""><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=""><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="">I added a separate section on Ambiguity and what the behavior is. I think you should be able to resolve ambiguity by casting so I went ahead and put that in. An example:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo; color: rgb(75, 209, 87);" class=""><div style="margin: 0px; font-size: 11px; line-height: normal; color: rgb(0, 132, 0);" class=""><div style="margin: 0px; line-height: normal;" class="">//Bar and Foo bridge to SomeObjectiveCType</div><div style="margin: 0px; line-height: normal; color: rgb(79, 129, 135);" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">struct</span><span style="" class=""> Bar<T>: </span>ObjectiveCBridgeable<span style="" class=""> { }</span></div><div style="margin: 0px; line-height: normal; color: rgb(79, 129, 135);" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">struct</span><span style="" class=""> Foo<T>: </span>ObjectiveCBridgeable<span style="" class=""> { }</span></div><div style="margin: 0px; line-height: normal; min-height: 13px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">class</span> API {</div><div style="margin: 0px; line-height: normal;" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">let</span> foo: <span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">Foo</span><<span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int</span>></div><div style="margin: 0px; line-height: normal;" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">func</span> objCVersionOfAFunction(obj: <span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">SomeObjectiveCType</span>) -> <span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">SomeObjectiveCType</span> {</div><div style="margin: 0px; line-height: normal;" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">let</span> x = obj <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">as</span>! <span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">Bar</span><<span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int</span>></div><div style="margin: 0px; line-height: normal;" class=""><span style="" class=""> </span>// We've told the compiler which protocol impl to call</div><div style="margin: 0px; line-height: normal; color: rgb(79, 129, 135);" class=""><span style="" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">return</span><span style="" class=""> </span>foo<span style="" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">as</span><span style="" class="">! </span>SomeObjectiveCType</div><div style="margin: 0px; line-height: normal;" class=""> }</div><div style="margin: 0px; line-height: normal;" class="">}</div></div></div></div><div class=""><br class=""></div><div class="">Any problems with this approach? It makes handling the ambiguous or manual bridging case relatively straightforward, though there may be objections to using casting this way. [Be careful, I still mourn the loss of @conversion so I’m biased :)]</div></div></div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">The problem I have with allowing the ambiguity is that you can get weird behavior if Bar and Foo are in different modules: import just Bar’s module, and an Objective-C API mentioning SomeObjectiveCType gets bridged as a Bar. Import just Foo’s module, and an Objective-C API mentioning SomeObjectiveCType gets bridged as a Foo. Import both, and SomeObjectiveCType doesn’t get bridged! Now start splitting class hierarchies among those modules and you get some very inconsistent imports… that’s why I think this needs to be an error.</div><br class=""></div></div></div></blockquote><div><br class=""></div><div>The rule requiring the Swift and @objc types to be in the same module wouldn’t allow the scenario you describe.</div><div><br class=""></div><div>I’m fine to say it’s an error as this isn’t a capability I have any use for and it definitely could cause confusion. The rule could always be relaxed in the future if there’s a convincing case for it. I’ll update the proposal to make it an error again.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><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="">We could just say that we aren’t going to let people have that level of granularity. Then just introduce a BuiltInBridgeable protocol that supersedes ObjectiveCBridgeable. A type adopting both will cause the compiler to prefer the built-in protocol when generating a bridging header, but the collection types can ignore that and just use ObjectiveCBridgeable. Presumably the BuiltInBridgeable protocol would just have an associated type to indicate that the bits are directly mapped to BuiltIn.Word or whatever.</div></div></div></div></blockquote><div class=""><br class=""></div>Yes, that’s a reasonable approach. I don’t think it’s important for this proposal.</div></div></blockquote><div><br class=""></div><div>I added some wording about magic built-in types like `Int` and a section at the bottom about the overall issue and an overriding protocol, but indicated we won’t pursue it at this time.</div><div><br class=""></div><br class=""><blockquote type="cite" 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="">Two last comments came up, then I’d like to merge and schedule this:</div><div class=""><br class=""></div><div class="">(1) isBridgedToObjectiveC should be a computed property, not a function</div></div></blockquote><blockquote type="cite" 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="">(2) Please add something indicating that, while one can “as” cast between a value type and its bridged Objective-C type, there are no implicit conversions. We currently have implicit conversions from String -> NSString, Array<T> -> NSArray, Dictionary<K, V> -> NSDictionary, and Set<T> -> NSSet, but we’re not happy about them and we don’t want to create more implicit conversions [*].</div><div class=""><br class=""></div></div></blockquote><div><br class=""></div><div>Done!</div><div><br class=""></div></div><div><br class=""></div><div><br class=""></div><div>Russ</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>