> On Mar 22, 2017, at 10:41 PM, Slava Pestov via swift-evolution
> <[email protected]> wrote:
>
>
>> On Mar 22, 2017, at 10:35 PM, Robert Widmann via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> Alternatives considered
>>
>> Do nothing and continue to accept this implicit conversion.
>
> One alternative would be to import CFArray as a typealias for NSArray, etc,
> erasing the distinction between the two types completely. I did suggest this
> to Jordan at one point and he pointed out some problems, but I don’t remember
> them now. Hopefully Jordan can chime in.
I'd prefer this solution as well, especially since toll-free bridged CF types
are nearly indistinguishable from their NS counterparts at runtime, so trying
to maintain the distinction for dynamic casts or reflection has historically
been problematic. Part of the problem is that, as Charlie noted,
CFArray/Dictionary/Set can take an arbitrary set of retain/release callbacks,
in which case the resulting container isn't fully NSArray-compatible. I'm not
sure that happens often enough with CF containers in the SDKs that accounting
for that case is worth the burden of separating the types.
-Joe
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
