Skip to content

[3.0] [AnyHashable] Handle comparisons/casting for wrappers around bridged types #4953

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

Merged
merged 1 commit into from
Sep 23, 2016

Conversation

DougGregor
Copy link
Member

Swift value types are their bridged Objective-C classes can have
different hash values. To address this, AnyHashable's responds to the
_HasCustomAnyHashableRepresentation protocol, which bridge objects of
those class types---NSString, NSNumber, etc---into their Swift
counterparts. That way, we get consistent (Swift) hashing behavior
across platforms.

However, there are cases where multiple Swift value types map to the
same Objective-C class type. In such cases, AnyHashable ends up
converting the object of class type back to some canonical type. For
example, an NS_STRING_ENUM (such as (NS)RunLoopMode) is a Swift
wrapper around a String. If an (NS)RunLoopMode is placed into an
AnyHashable, it maintains it's Swift type identity (which is correct
behavior). If it is bridged to Objective-C, it becomes an NSString; if
that NSString is placed into an AnyHashable, it produces a String. The
hash values still line up, but equality of the AnyHashable values
fails, which breaks when (for example) a dictionary with AnyHashable
keys is used from Objective-C. See SR-2648 / rdar://problem/27992351
for a case where this breaks interoperability.

To address this problem, make AnyHashable's casting and equality
sensitive to the origin of the hashed value: if the AnyHashable was
created through a _HasCustomAnyHashableRepresentation conformance,
treat comparisons/casting from it as "fuzzy":

  • For equality, if one of the AnyHashable's comes from a custom
    representation (e.g., it originated with an Objective-C type like
    NSString) but the other did not, bridge the value of the other
    AnyHashable to Objective-C, re-wrap it in an AnyHashable, and
    compare that. This allows, e.g., an (NS)RunLoopMode created in Swift
    to compare to an NSString constant with the same string value.
  • For casting, if the AnyHashable we're casting from came from a
    custom representation and the cast would fail, bridge to Objective-C
    and then initiate the cast again. This allows an NSString to be
    casted to (NS)RunLoopMode.

Resolves SR-2648 / rdar://problem/27992351.

(cherry picked from commit 6f34118)

…types.

Swift value types are their bridged Objective-C classes can have
different hash values. To address this, AnyHashable's responds to the
_HasCustomAnyHashableRepresentation protocol, which bridge objects of
those class types---NSString, NSNumber, etc---into their Swift
counterparts. That way, we get consistent (Swift) hashing behavior
across platforms.

However, there are cases where multiple Swift value types map to the
same Objective-C class type. In such cases, AnyHashable ends up
converting the object of class type back to some canonical type. For
example, an NS_STRING_ENUM (such as (NS)RunLoopMode) is a Swift
wrapper around a String. If an (NS)RunLoopMode is placed into an
AnyHashable, it maintains it's Swift type identity (which is correct
behavior). If it is bridged to Objective-C, it becomes an NSString; if
that NSString is placed into an AnyHashable, it produces a String. The
hash values still line up, but equality of the AnyHashable values
fails, which breaks when (for example) a dictionary with AnyHashable
keys is used from Objective-C. See SR-2648 / rdar://problem/27992351
for a case where this breaks interoperability.

To address this problem, make AnyHashable's casting and equality
sensitive to the origin of the hashed value: if the AnyHashable was
created through a _HasCustomAnyHashableRepresentation conformance,
treat comparisons/casting from it as "fuzzy":

* For equality, if one of the AnyHashable's comes from a custom
  representation (e.g., it originated with an Objective-C type like
  NSString) but the other did not, bridge the value of the *other*
  AnyHashable to Objective-C, re-wrap it in an AnyHashable, and
  compare that. This allows, e.g., an (NS)RunLoopMode created in Swift
  to compare to an NSString constant with the same string value.
* For casting, if the AnyHashable we're casting from came from a
  custom representation and the cast would fail, bridge to Objective-C
  and then initiate the cast again. This allows an NSString to be
  casted to (NS)RunLoopMode.

Fixes SR-2648 / rdar://problem/27992351.

(cherry picked from commit 6f34118)
@DougGregor DougGregor added this to the Swift 3.0 milestone Sep 23, 2016
@DougGregor
Copy link
Member Author

@swift-ci please test macOS

@DougGregor DougGregor assigned DougGregor and tkremenek and unassigned DougGregor Sep 23, 2016
@tkremenek
Copy link
Member

Wow, great work fixing this.

@tkremenek tkremenek merged commit a480b51 into swiftlang:swift-3.0-branch Sep 23, 2016
@DougGregor DougGregor deleted the sr-2648-3_0 branch September 23, 2016 18:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants