> On Nov 10, 2016, at 11:51 AM, Matthew Johnson <matt...@anandabits.com> wrote:
>
>>
>> On Nov 10, 2016, at 1:44 PM, Joe Groff <jgr...@apple.com
>> <mailto:jgr...@apple.com>> wrote:
>>
>>>
>>> On Nov 10, 2016, at 11:42 AM, Matthew Johnson <matt...@anandabits.com
>>> <mailto:matt...@anandabits.com>> wrote:
>>>
>>>
>>>> On Nov 10, 2016, at 1:34 PM, Joe Groff via swift-dev <swift-...@swift.org
>>>> <mailto:swift-...@swift.org>> wrote:
>>>>
>>>>
>>>>> On Nov 10, 2016, at 10:30 AM, Philippe Hausler <phaus...@apple.com
>>>>> <mailto:phaus...@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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
