I don't think you'll get a satisfactory answer to this. It is just a design decision, like a thousand others that shaped Cocoa. Even if the people who originally made the decision back in the day were to show up and explain, the explanation would always necessarily boil down to "it's what seemed best to us". That is, it's clearly possible to design and implement collection classes that can hold nil
and any justification for not supporting that is going to be contestable. Somebody will object that the justification doesn't make sense to them vs. the justification for doing it the other way. At that point it's just subjective judgment.
That said, here are a couple of issues:
- Suppose
[dict objectForKey:@"myKey"]
returnsnil
. Is that becausenil
was added as the value for@"myKey"
or because no value was added for that key? - Dictionaries and sets (and even
NSArray
methods like-containsObject:
and-indexOfObject:
) use-isEqual:
to test object equality. However,[nil isEqual:anything]
will always return false. Therefore, you'd never be able to findnil
in the collection. You could overcome this with extra checks fornil
, but that a) violates the design contract that-isEqual:
is used to determine equality, and b) imposes implementation costs. - Methods like
-lastObject
,-firstObject
, and-anyObject
returnnil
when there are no objects in the collection. How do you distinguish that from returning anil
that's a member of the collection? Similarly, for-[NSEnumerator nextObject]
.