Whoa, Richard.  I think you are way over-interpreting my words as
advocating lack of documentation, or lack of checks for common bugs.  I
am doing no such thing.

You made a blanket assertion, that methods should not ever return
garbage silently, and that it is their responsibility to make sure that
such results are prevented.  I am not arguing that trying to prevent
them from doing so is not good.  I simply demonstrated that such a
blanket assertion is just not true, and can't be made true, no matter
how much we both wish it was true.

I entirely agree that not having such aliasing problems would be
fantastic; but all the languages you listed are non-imperative, and
Smalltalk is imperative.  I love the fact that this kind of problem
doesn't happen in non-imperative languages, but that doesn't make
Smalltalk one, and it doesn't make it possible to make Smalltalk act
that way in general, which is what your blanket statement requires.

All the things you want in terms of documentation, and detection of
interface violations are good, but we disagree profoundly about where
such checks belong.  I think that they simply don't in general belong in
the main runtime code path, they belong in separate assertions or
pre/postconditions whose cost can be made zero in production.

We also disagree profoundly about whether (x removeAll: x) makes sense
*as the library is written*.  I think it just doesn't, and I explained
why, so this input is not part of the expected domain of the method.
You disagree- 'nuf said.  However, I think that it is a common bug that
almost everyone makes at some point, and so catching it would be a "good
thing".   I think the reason that passing the receiver as an argument is
not supported right now is that most often, that's not the most
efficient way to do it, so it is not necesarily desirable to encourage
emptying a collection this way.  It is almost always more efficient and
just as convenient, to just create a new collection.   Extending the
library to support using (x removeAll: x) to empty a collection in-place
sounds potentially reasonable to me if its importance could be
justified- but I do not believe the method as currently written is
broken, and that is our real disagreement.

Cheers,
Dave