<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On May 12, 2017, at 1:18 PM, Víctor Pimentel Rodríguez &lt;<a href="mailto:vpimentel@tuenti.com" class="">vpimentel@tuenti.com</a>&gt; wrote:</div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Fri, May 12, 2017 at 6:56 PM, John McCall via swift-evolution <span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I assume you're talking about the type restrictions on exporting Swift functions as @objc.&nbsp; 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.&nbsp; Today, that policy is to allow export when there's an obvious, idiomatic analogue in Objective-C.&nbsp; Exporting Int? as an optional NSNumber does not feel obvious and idiomatic when we would export Int as NSInteger.&nbsp; It feels like reaching for an arbitrary solution.</blockquote></div><br class="">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&lt;NSNumber *&gt; *.</div></div></div></blockquote><div><br class=""></div>We certainly do this. &nbsp;But we have, historically, driven a line between doing this and allowing it in exports. &nbsp;That's all I'm saying.</div><div><br class=""></div><div>John.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra">For such purposes Swift already has types like _SwiftTypePreservingNSNumber , a subclass of NSNumber.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">If that can apply to Array&lt;Int&gt; or Dictionary&lt;Int, Int&gt;, the same reasoning can be applied to the Optional&lt;Int&gt;.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">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.</div><div class="gmail_extra"><div class=""><br class=""></div>--&nbsp;</div><div class="gmail_extra">Víctor Pimentel<div class="gmail_signature"><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" style="font-size:12.8px" class=""><div style="font-size:12.8px" class=""></div></div></div></div></div></div></div></div></div></div></div>
</div></div>
</div></blockquote></div><br class=""></body></html>