> On Nov 10, 2016, at 10:30 AM, Philippe Hausler 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
> op
A quick ping. I'd like some feedback about how to address this problem.
-Joe
> On Nov 2, 2016, at 10:26 AM, Joe Groff via swift-dev
> wrote:
>
> There's a hole in our AnyHashable implementation when it comes to what I'll
> call "pure" NSNumbers coming from Cocoa, which were instantiated using
There's a hole in our AnyHashable implementation when it comes to what I'll
call "pure" NSNumbers coming from Cocoa, which were instantiated using
-[NSNumber numberWith*:] factories or @(n) syntax in Objective-C. While we
maintain type specificity when Swift number types are bridged through NSNu
