On Fri, 13 Nov 2009, Igor Stasenko wrote:

> You are right, that currently developer expects to see an error if nil
> been added to set.

I doubt that anyone ever wrote error handling code around #add:. 
Developers expect that the value they add to a Set is not nil, and they 
don't expect to get an error at all.

> But i don't agree that adding new sets could make tracking down an
> error(s) any harder, because see, we having
> a lot of different collection types, which allow nils from very
> starting and i never head of anyone
> complaining that it makes debugging any harder because of nils or any
> other object which sits in collection(s).

Sets are not ment to be used for error detection.

> My proposal is to make two different classes, one which allows nils,
> other throws an error , as currently does.
> But again, i don't wanna see references to new globals in code, like:
> SetWithNils new
>
> instead, if user wants to explicitly state what kind of set he prefers
> to use, he should do it using a message:
>
> [Identity]Set withoutNils new
> or
> [Identity]Set withNils new
>
> and by default
> Set new
>
> should be Set withNils , so later when critical mass will emerge we
> could see, based on how often it used,
> if we may simply deprecate #withoutNils and remove obsolete interface
> from system, or instead leave it as is.
>

Duplicating the number of set classes sounds like a really bad idea. If 
changing the current behavior is such a big issue (which I doubt), then we 
shouldn't change the current behavior.

Levente