"David Griswold" <David.Griswold at acm.org> wrote:
	Maybe someone already pointed this out, but this whole discussion about
	(x removeAll: x) is just a slippery slope that simply *can't* be solved
	generally in an imperative language.

	So the solution is: the library is fine; this is "operator error".

The library is broken in at least two ways:
(1) The documentation says NOTHING about the two collections having to be
    different.
(2) If an operation isn't going to work, it should bring that to our
    attention instead of quietly producing incorrect answers.

If removeAll: had the form

    removeAll: aCollection
	"Remove each element of aCollection from the receiver.
	 If successful for each, answer aCollection.
	 Otherwise, create an error notification.
	 ArraysCollections cannot respond to this message.
	 This message cannot work if aCollection == the receiver,
	 because then the result would have to be empty and would
	 have to contain all the original elements at the same time."

	aCollection == self
	    ifTrue: [self error: 'Cannot remove a collection from itself'].
	aCollection do: [:each | self remove: each].
	^aCollection

then David Griswold _would_ be right, the library _would_ be fine.
But it simply won't do for the operation to quietly do the wrong thing.
Now, testing whether aCollection == self is pretty darned cheap compared
with everything else that's going on.  It appears to be unavoidable if
it's to behave sanely.  So when there is a fix that makes the operation
WORK in the previously forbidden case, thus simplifying what a programmer
has to understand, and this fix does not increase the cost of the cases
that used to work, why NOT fix it?