Open Radar

 
Summary:
+[NSDictionary(NSSharedKeySetDictionary) sharedKeySetForKeys:] returns an opaque "id" type, which is actually an instance of the private NSSharedKeySet. It's clearly a well-implemented collection which secretly conforms to NSCopying, NSCoding, and NSFastEnumeration and has since the feature was added to the SDK. I understand hiding the implementation detail of the class itself, but it would make sense to expose those protocol conformance for the opaque token

Steps to Reproduce:
1. Create a project that fills a dictionary using a parameterized set of keys.
2. Attempt to switch to shared key sets.
3. Continue to need to enumerate through the key array.
4. Be sad.

Expected Results:
The shared key set fundamentally involves holding on to the passed keys, and is explicitly documented as copying them. For parameterized implementations that might want to use shared key dictionaries, it is vital to be able to enumerate through the known set of keys.

Actual Results:
The shared key set is a completely opaque token; implementations require caching both the original array of keys and the resulting key set, which is wasteful when the key set already implements this functionality.

Version:
Xcode 6.0 DP7 (6A280n)

Notes:
Obviously, if one just assumes that the shared key set conforms to fast enumeration, the functionality works, but in order to account for the possible removal of that feature, the array of keys must also be cached which is still wasteful. An API guarantee for this already implemented functionality would be extremely nice.

Configuration:
Occurs under all versions of Foundation 945 and up, i.e., beginning in Mac OS X 10.8 and iOS 6.0.

Attachments: