[SR-2393] Some integer types are not bridged with `NSNumber`

[jadengeller]

Previous ID	SR-2393
Radar	rdar://problem/18025596
Original Reporter	@JadenGeller
Type	Bug
Status	Reopened
Resolution

Environment

Swift 3, Xcode 8 beta 6

Additional Detail from JIRA

Votes	0
Component/s	Compiler, Foundation
Labels	Bug, ClangImporter
Assignee	None
Priority	Medium

md5: 85a929ddca7c72d48a026af105f5baa4

Issue Description:

None of `Int8`, `Int16`, `Int32`, and `Int64` are bridged to `NSNumber`. This is surprising behavior and caused a crash in production code.

[belkadan]

The Foundation team decided not to bridge these a long time ago.

[jpsim]

I'm sure this decision happened pre-Swift Evolution days and that the thought process likely wasn't documented, but on the off chance that it was, is that available anywhere?

[jadengeller]

@jckarter seemed to think that this decision was due implicit bridging problems. For example, `Int64` would implicitly bridge to `Int8` through `NSNumber`. Now that implicit bridging is removed from the language, it seems reasonable to extend bridging behaviors, no?

[jckarter]

Yeah, I remember that being a major influence on our original decision. We ought to reevaluate our decision in light of id-as-Any and the removal of implicit bridging conversions. The lack of bridging for some number types is catching a lot of users by surprise.

[belkadan]

Well, okay. That's still mostly a Foundation decision.

[jadengeller]

What we're doing in the meantime is gross 😛
https://github.com/realm/realm-cocoa/blob/jg-optional-bridgable/RealmSwift/Util.swift#L53

It would be so much nicer if we could just pass as `Any` and have it exposed as the proper bridged type in Objective-C and receive back as `Any` and force cast to a Swift-compatible type.

[mattneub]

A related problem now (at least I think it's related) is that anything can cross the bridge, so the compiler no longer stops you from doing something that Objective-C can't cope with. This is legal:

anim.values = [oldP,p1,p2,newP]

where anim is a CAKeyframeAnimation and the things in the array are CGPoints. The compiler used to stop you because a CGPoint is not an AnyObject; now it doesn't. People are going to be very surprised when their animation doesn't work as expected.

This new "permissive boxing" (if I may so express it) is going to be a massive trap, I predict. StackOverflow here we come. A good solution might be for Swift to wrap in NSValue objects; that's why I say this is related to the NSNumber behavior.

[jadengeller]

+1 on making the boxed Swift values a subclass of `NSValue`. I'd be interested in knowing if there's a reason they are not.

[belkadan]

They aren't NSValues because most of them aren't trivially copyable. In theory we could use NSValue for imported types and @objc enums, though. But please put that in a separate bug.

[mattneub]

@belkadan Will do.

[jckarter]

At minimum, we could make the common NS/CG structs (the ones with existing NSValue factories) individually bridge to NSValue.

[mattneub]

That is in fact what I mean. I'll modify my other bug to clarify.