[swift-evolution] Swift's Optional Int as NSNumber in Objective-C
rjmccall at apple.com
Fri May 12 13:21:33 CDT 2017
> On May 12, 2017, at 1:18 PM, Víctor Pimentel Rodríguez <vpimentel at tuenti.com> wrote:
> On Fri, May 12, 2017 at 6:56 PM, John McCall via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I assume you're talking about the type restrictions on exporting Swift functions as @objc. We have the technical ability to bridge any Swift value to Objective-C as an opaque object, but that wouldn't actually produce meaningful APIs on the ObjC side; we have to have some sort of tighter policy than that. Today, that policy is to allow export when there's an obvious, idiomatic analogue in Objective-C. Exporting Int? as an optional NSNumber does not feel obvious and idiomatic when we would export Int as NSInteger. It feels like reaching for an arbitrary solution.
> Actually Swift already export Ints as NSNumbers in other contexts when types like Int are used in generic constraints, particularly value types like Array or Dictionary. For example, a variable of type [Int] gets bridged over as a NSArray<NSNumber *> *.
We certainly do this. But we have, historically, driven a line between doing this and allowing it in exports. That's all I'm saying.
> For such purposes Swift already has types like _SwiftTypePreservingNSNumber , a subclass of NSNumber.
> If that can apply to Array<Int> or Dictionary<Int, Int>, the same reasoning can be applied to the Optional<Int>.
> I mean, I'm not saying that there are no reasons to disallow it, but it doesn't seem an arbitrary solution if in other contexts Swift is already doing that.
> Víctor Pimentel
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution