> On Nov 10, 2016, at 10:30 AM, Philippe Hausler <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. Since those are almost always tagged pointers, or at least pooled and cached on platforms that don't support tagged pointers, the overhead of then having AnyHashable push numbers into NSNumbers would be less. -Joe _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
