still no one came up with any good reason to allow nils into sets.

As I said it sounds like much ado about nulls a la :

dbdebunk.com

viz:

http://www.dbdebunk.com/page/page/2928212.htm

or

http://www.dbdebunk.com/page/page/3317151.htm

Like I say, I still have no reall idea why people have this desire to
perform hacks based on nulls

/me vomits in a corner based on a null or ten million

2009/11/12, Ralph Boland <rpboland at gmail.com>:
> I appreciate that being able to add nil to a Set is useful.
> All the discussion so far seems to be based upon how to
> implement such a change efficiently and safely.
>
> I would like to point out that there is a negative to allowing
> nil to be added to a set and as it happens it applies to
> every instance of Set I have ever used (at least directly).
>
> A common bug in programs is to have an object set to nil
> when the programmer believes the object cannot have value nil,
> for example when the programmer has forgotten to initialize a variable.
>
> Currently, if such an object is added to a set an error will occur.  The
> programmer must then from this point determine why the object
> has value nil.  If sets are modified as proposed no error will
> occur!!!!!!!!!!!
> Since there is a bug, someday the programmer will discover there is
> a problem and after some debugging effort determine that the set contains
> the element nil (and hopefully recognize that it shouldn't).  (S)he must
> then track down the point that nil was added to the set and thus what object
> unexpectedly has the value nil.  (S)he then is exactly where s(he) would
> have
> been right away if Sets report an error on addition of nil.
>
> Assuming that nearly all uses of Set do not expect nil to be a possible
> entry,
> I propose the following:
>
> 1)  Add Set method  addUnlessNil: object.
> This method does nothing quietly if  object == nil.  Otherwise it does
>  add: object.
>
> 2) Add Set method  addEvenNil: object.
>  This method adds nil to the set in some convoluted way that allows
> nil to be used
>  for the unused entries in the set.
>
> 3) Add any supporting methods such as  includesNil  and removeNil  that
> might
>     be needed.
>
> This proposal is of course UGLY for applications needing to add nil to sets.
> For example, if one wants to add a collection to a  set then one now needs
> methods  addAllEvenNil:  and  addallUnlessNil:.
> It does have the following advantages though.
>   a) It is totally backwards compatible.
>   b) There is no performance penalty except when adding nil to a set.
>   c) Situations where nil may be added to a set are clearly marked.
>
> Of course my proposal rests on the assumption that
> nearly all uses of Set do not expect nil to be a possible entry.
> I believe this to be true.
> Even if my proposal is not accepted the assumption implies that whatever
> choice is made should be efficient so as not to penalize all the
> applications
> that do not add nil to sets.
>
> An interesting side note is that one could argue that my proposal should
> apply
> to collections in general.  Regardless of how convinced of this one is
> however,
> the fact remains that such a change would break a  LOT OF CODE
> (including some of mine) and thus be very difficult to implement in
> practice.
> Regards,
>
> Ralph Boland
>
> --
> Volume * Density = Mass.
> Volume / Density = Intelligence.
> The latter equation explains the
> essentially equal intelligence of men and woman
> and the capabilities of some commonly used operating systems.
>
>