[SR-3172] Set<AnyHashable> isn't bridging to NSNumber correctly

[ChristopherRogers]

Previous ID	SR-3172
Radar	rdar://problem/29026017
Original Reporter	@ChristopherRogers
Type	Bug
Status	Closed
Resolution	Done

Environment

Xcode 8.1, Swift 3.0.1
Xcode 8.1, Development Snapshot 2016-11-09

Additional Detail from JIRA

Votes	0
Component/s	Standard Library
Labels	Bug, SDKOverlay
Assignee	None
Priority	Medium

md5: 7c87927e15a61fb97e3113802a6eade2

Issue Description:

All of these statements except the last evaluate to true. I believe it should be true as well. This affects Swift to Objective-C bridging where the Objective-C code isn't using lightweight generics.

([42] as Array as NSArray).contains(42)
([42] as Array as NSArray).contains(NSNumber(value: 42))
([42] as Array<AnyHashable> as NSArray).contains(42)
([42] as Array<AnyHashable> as NSArray).contains(NSNumber(value: 42))
([42] as Set as NSSet).contains(42)
([42] as Set as NSSet).contains(NSNumber(value: 42))
([42] as Set<AnyHashable> as NSSet).contains(42)
([42] as Set<AnyHashable> as NSSet).contains(NSNumber(value: 42)) // false

[belkadan]

cc @jckarter, @DougGregor

[jckarter]

Yeah, we don't properly handle "pure" NSNumbers from Cocoa, since they don't have a definitive Swift type to hash and equate like (rdar://problem/29026017).

[DougGregor]

Huh. Still fails with master; @jckarter, is this still a known gap in our `AnyHashable` story for `NSNumber`?

[jckarter]

Yes, I emailed swift-dev about this a couple weeks ago:

https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20161031/003401.html

[ChristopherRogers]

NSNumber(value: 42) as AnyHashable == 42 as AnyHashable now returns true for me in Swift 3.2 & 4.0.

[jckarter]

Yeah, looks like @phausler's changes to NSNumber bridging addressed this.