[swift-evolution] [swift-dev] Pure Cocoa NSNumbers and AnyHashable

[Joe Groff]

> On Nov 10, 2016, at 11:51 AM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
>> 
>> On Nov 10, 2016, at 1:44 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>> 
>>> 
>>> On Nov 10, 2016, at 11:42 AM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>>> 
>>> 
>>>> On Nov 10, 2016, at 1:34 PM, Joe Groff via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>>> 
>>>> 
>>>>> On Nov 10, 2016, at 10:30 AM, Philippe Hausler <phausler at apple.com <mailto:phausler at apple.com>> wrote:
>>>>> 
>>>>> So I think there are a few rough edges here not just the hashing or equality. I think the issue comes down to the subclass of NSNumber that is being used - it is defeating not only hashing but also performance and allocation optimizations in Foundation.
>>>>> 
>>>>> So what would we have to do to get rid of the “type preserving” NSNumber subclass?
>>>> 
>>>> The type-preserving subclasses remember the exact Swift type that a value was bridged from, to preserve type specificity of casts so that e.g. `0 as Any as AnyObject as Any as? Float` doesn't succeed even if the Any <-> AnyObject round-trip involves ObjC, thereby providing somewhat more consistent behavior between Darwin and Corelibs-based Swift. If we were willing to give that up, and say that NSNumbers just flat-out lose type info and can cast back to any Swift number type, then it seems to me we could use the pure Cocoa subclasses.
>>> 
>>> Would these only be value-preserving casts and return nil if information loss would occur?  I think that might be preferable anyway.  Maybe I’m just not thinking hard enough, but when would the original type information be important as long as information isn’t lost?  When I interact with these casts and NSNumber (JSON parsing, etc) I generally *do not* want an attempted cast that would be value-preserving to ever fail.
>> 
>> I'm inclined to agree that the cast should be value-preserving rather than type-preserving. There was concern about the behavior being different on Darwin and Linux, which is why we try to be type-preserving so that pure Swift code that uses number values with Any or other polymorphic interfaces behaves consistently with Cocoa Foundation code that has to traffic in NSNumber for the same effect.
> 
> Are you saying that Swift on Darwin can’t have value-preserving behavior?  It seems like I’m missing something here.  If value-preserving is the desirable behavior can you elaborate on the specific challenges getting in the way of having that behavior everywhere?

It would require a change to the type relationships between the number value types on Swift. They are currently plain, unrelated struct types, so you can't do something like:

	let x: Int = 1
	x as? Float // produces nil

We could conceivably special-case the number types in Swift so that they do value-preserving casts, and maybe that's even a good idea, but we don't today.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161110/94ef7701/attachment.html>