[swift-evolution] [Idea] ObjectiveCBridgeable

[Russ Bishop]

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

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.


> 
>> 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.
> 
> Yes, that’s a reasonable approach. I don’t think it’s important for this proposal.

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.


> 
> Two last comments came up, then I’d like to merge and schedule this:
> 
> (1) isBridgedToObjectiveC should be a computed property, not a function
> 
> (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 [*].
> 

Done!



Russ




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