[swift-evolution] [Idea] ObjectiveCBridgeable

[Douglas Gregor]

> On Mar 24, 2016, at 12:39 AM, Russ Bishop <xenadu at gmail.com> wrote:
> 
> 
>>> 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:
>>> 
>>> //Bar and Foo bridge to SomeObjectiveCType
>>> struct Bar<T>: ObjectiveCBridgeable { }
>>> struct Foo<T>: ObjectiveCBridgeable { }
>>> 
>>> class API {
>>>     let foo: Foo<Int>
>>>     func objCVersionOfAFunction(obj: SomeObjectiveCType) -> SomeObjectiveCType {
>>>         let x = obj as! Bar<Int>
>>>         // We've told the compiler which protocol impl to call
>>>         return foo as! SomeObjectiveCType
>>>     }
>>> }
>>> 
>>> 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 :)]
>> 
>> 
>> 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.
>> 
> 
> The rule requiring the Swift and @objc types to be in the same module wouldn’t allow the scenario you describe.

Ah, yes.

> 
> 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.

I’d rather call it an error and consider relaxing the rule if we find it’s very important later on.

	- Doug


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160324/cd95a844/attachment.html>