That's an interesting way to look at the situation, but do note that most Smalltalkers will be suprised to find those assertions or corrections in removeAll:. Most fooAll: methods just do: on the argument and foo: each element, and have no particular protection against #foo: modifying the argument.
What is this last statement based on? Is it the Squeak image? Using the MethodFinder and looking at all methods with "all:" I can actually not find many methods that " just do: on the argument and foo: each element"...
The only ones I found (a cursory look) where:
Collection>>addAll: Collection>>removeAll: CompositeEvent>>addAll: POSimplePolygon>>addAll:
And I also found that OrderedCollection>>addAll: and SortedCollection>>addAll: does NOT do that! Of course, what they do is equivalent to "just do: and foo:" but it is still different code.
Further I found quite a lot of methods named "somethingAll:" but the only thing I can see that they have in common is that they take an argument that is intended to be a Collection of something. That is all.
Which, of course, concedes the point that fooAll: methods entail an implied iteration on its parameter.
Even if the statement was correct (which I do not agree with Lex, at least not if we look at the image) it would only show that most such methods where *implemented* that way. IMHO it doesn't "imply" anything.
I've been programming Smalltalk for a while, and I know what the implicitions are the same way I know what words in my native tongue mean. By itself, the "all" implies that the argument is a collection. If it's "fooAll:" where "foo" is a verb, and especially if there exists a "foo:" method in parallel, then I stand by claiming that the expectation is that the method will iterate over the argument and perform a "foo" on all of them.
Your data actually agrees with this analysis. I didn't mean to say that the methods were *implemented* to literally use #do:. In fact, a primary reason to have optimized implementations of removeAll: is to get rid of the explicit iteration. Nevertheless, they will examine the elements of the argument in some fashion. It seems a very heavy burden to require them to tolerate the argument changing as the method does it's work. As a general rule, experienced Smalltalkers will not expect methods should to cope with their arguments changing while the method progresses. When they do,
The ability to cope with such is extraordinary and often imposes a large implementation burden.