> On May 12, 2017, at 1:18 PM, Víctor Pimentel Rodríguez <vpimen...@tuenti.com> > wrote: > On Fri, May 12, 2017 at 6:56 PM, John McCall via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
