[SR-7436] Open-source Foundation is missing most AnyHashable representations

[lorentey]

Previous ID	SR-7436
Radar	rdar://problem/39434747
Original Reporter	@lorentey
Type	Bug
Status	In Progress
Resolution

Additional Detail from JIRA

Votes	0
Component/s	Foundation
Labels	Bug
Assignee	@lorentey
Priority	Medium

md5: 4d3513cd1638ab2defe58f984baea9fe

Issue Description:

The open-source Foundation package currently doesn't define _HasCustomAnyHashableRepresentation conformances for the following types:

NSAffineTransform
NSArray
NSCalendar
NSCharacterSet
NSDate
NSDateComponents
NSDateInterval
NSDictionary
NSLocale
NSNotification
NSNumber
NSSet
NSString
NSTimeZone
NSURL
NSURLComponents
NSURLQueryItem
NSURLRequest

To improve consistency across platforms, we need to ensure these types hash the same way under AnyHashable as their corresponding Swift types.

[lorentey]

@swift-ci create

[lorentey]

This is a bit more difficult as it seems. While we can easily conform swift-corelibs-foundation types to _HasCustomAnyHashableRepresentation, it is currently pointless to do so, because such conformances have no effect unless the Objective-C runtime is present. (This seems like an artificial restriction to me, but I doubt I fully grok AnyHashable's runtime components yet.)

I believe AnyHashable should work the same way on all platforms; therefore, ideally we should implement support for _HCAHR everywhere.

[belkadan]

I don't think we'd originally wanted to do that for AnyHashable (there was no need). Now that we're investigating bridging on Linux, that decision may change. cc @jckarter, @millenomi

[jckarter]

The only thing that makes custom AnyHashable representations necessary is bridging, yeah. If we do bridging on Linux we'd need to implement this, but as it stands it's not needed.

[lorentey]

The Objective-C runtime requirement is now gone for AnyHashable, and bridging works on Linux.

All that remains to be done is adding the conformances, so I'll do that now.

[lorentey]

PR with the fix is at #1649