> On Nov 10, 2016, at 1:44 PM, Joe Groff <[email protected]> wrote: > >> >> On Nov 10, 2016, at 11:42 AM, Matthew Johnson <[email protected]> wrote: >> >> >>> On Nov 10, 2016, at 1:34 PM, Joe Groff via swift-dev <[email protected]> >>> wrote: >>> >>> >>>> On Nov 10, 2016, at 10:30 AM, Philippe Hausler <[email protected]> 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? > > -Joe
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
