>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
