[SR-3172] Set<AnyHashable> isn't bridging to NSNumber correctly Created: 10 Nov 2016  Updated: 10 Jul 2017  Resolved: 10 Jul 2017

Status: Closed
Project: Swift
Component/s: Standard Library

Type: Bug Priority: Medium
Reporter: Christopher Rogers Assignee: Unassigned
Resolution: Done Votes: 0
Labels: SDKOverlay

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

Radar URL: rdar://problem/29026017


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

Comment by Jordan Rose [ 10 Nov 2016 ]

cc Joe Groff, Doug Gregor

Comment by Joe Groff [ 10 Nov 2016 ]

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).

Comment by Doug Gregor [ 10 Nov 2016 ]

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

Comment by Joe Groff [ 10 Nov 2016 ]

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


Comment by Christopher Rogers [ 6 Jul 2017 ]

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

Comment by Joe Groff [ 10 Jul 2017 ]

Yeah, looks like Philippe Hausler's changes to NSNumber bridging addressed this.

Generated at Wed Jan 23 10:39:57 CST 2019 using Jira 7.13.0#713000-sha1:fbf406879436de2f3fb1cfa09c7fa556fb79615a.