> On Mar 24, 2016, at 12:39 AM, Russ Bishop <xen...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
