On Fri, May 12, 2017 at 6:56 PM, John McCall via swift-evolution < 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 *> *. 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