On Jan 8, 2016, at 13:44 , Etan Kissling <kissl...@oberon.ch> wrote:
> 
> a. Could be :-) However, since the Find feature of the minimal app stops 
> working properly after modifying the collection, there's definitely something 
> fishy.

I suspect the inability to display Set members comes from the fact that the 
debugger information says that the implementation is a Swift Set object, and 
the debugger isn’t capable of dealing with the situation where the actual 
object is a NSSet subclass**. Precisely where the bug is, is hard to say, but a 
bug report about the debugger seems like a good place to start.

The Xcode-hanging problem is probably a second bug. If the debugger thinks the 
object is a different class of object, then it may try to follow pointers, and 
that can take it very far afield. (After my bug report about this tendency, I 
was told that the debugger didn’t follow pointers for reference types by 
default. Apparently this meant that the 32 MB of output I attached to the bug 
report didn’t really exist.)

The debugger also seems to (still) have the bug where it confuses local 
variables that have the same name. In the method where you unwrap an optional 
‘object’ into a non-optional object, it told me that ‘object’ was a view 
controller, at the start of the method. It turned into a Foo a couple of lines 
later.

So, yes, multiple fishy things. Your sample project seems like excellent 
supporting evidence for bug reports.

> Swift's hashValue probably forwards to ObjC's hash, but not vice versa. 
> That's why it breaks in a strange way when I only override Swift's hashValue.
> As soon as the set is bridged to ObjC, the default hash is used and not my 
> customized one.

After I thought about this some more, I suspect there’s no direct built-in link 
between ‘hash’ and ‘hashValue’. My guess is that if you use ‘==‘ it uses 
‘hashValue’ for Swift objects, but that if ‘==' internally uses isEqual because 
the underlying objects are NSObjects, it’s going to use ‘hash’ automatically 
(modulo the misbehavior in the Swift bug report you mentioned).

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to