[swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions
jordan_rose at apple.com
Thu Mar 23 12:14:57 CDT 2017
> On Mar 23, 2017, at 09:05, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>> On Mar 22, 2017, at 10:41 PM, Slava Pestov via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> On Mar 22, 2017, at 10:35 PM, Robert Widmann via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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.
[adding Philippe, who has also thought about this problem]
The abstract problems I know of are:
(1) custom callbacks
(2) it's legal to import CF without importing Foundation
(3) CF types will not get generics
In practice, (1) is both exceedingly rare (only one public API that I know of) and something that can be worked around by using the CF APIs on the array—that is, we can keep CFArrayGetValueAtIndex around and just have it take an NSArray. (2) is something we can deprecate and/or fix. (3) just means we have to import the CFArray as NSArray rather than Array.
We would have to be very sure that all toll-free bridged CF types are marked as such; adding toll-free bridging would not be a backwards-compatible change since it would conflate two types into one. This leads us to a fourth problem: this is a source-breaking change if anyone has overloads for both CFArray and NSArray, or adds a protocol to CFArray that NSArray already has. We probably already need to solve the latter in some way, and could try to cross our fingers about the former.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution