Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ChristopherRogers opened this issue Nov 10, 2016 · 6 comments
Closed
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. SDKOverlay standard library Area: Standard library umbrella

Comments

@ChristopherRogers
Copy link
Contributor

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
Copy link
Contributor

cc @jckarter, @DougGregor

@jckarter
Copy link
Member

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
Copy link
Member

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

@jckarter
Copy link
Member

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
Copy link
Contributor Author

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

@jckarter
Copy link
Member

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

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. SDKOverlay standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

4 participants