On 9/21/2020 4:08 AM, Michael Kuhlmann wrote:
But after thinking about it, I'm now convinced that it would be a bad idea. Because it extends the scope of this small, tiny Iterable interface to something bigger which it shouldn't be.
This response captures the essence of the problem. You may think you are asking for "just one more method on Iterable", but really, what you are asking for is to turn Iterable into something it is not. Iterable exists not to be "smallest collection", but as the interface to the foreach-loop. Yes, we could have chosen a different design center for Iterable (Eclipse Collections did, see RichIterable), but we didn't. Adding this method merely sends the signal that we want to extend Iterable to be more than it is, which opens the floodgate to requests (and eventually demands) for more methods.
I can ask about Iterable#forEach - is it there only because it was there to begin with? Would it have been a bad idea to add one if we had streams already?
While you can make an argument that forEach is excessive, the fact that you make this argument illustrates the essential problem with this proposal. Your argument wrt forEach is "If that makes sense, then so does find." If you pull on that string, then this method forms the basis of tomorrow's assumption: "You have forEach and find, it is unreasonable to not add <my pet method>".
So, Iterable should stay simple. (The other arguments against it on this thread, are also valid, but this is the most important one.)
