[swift-evolution] Swift's Optional Int as NSNumber in Objective-C

[John McCall]

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

John.

> 
> 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...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170512/e7c3fe9b/attachment.html>