'Find' method for Iterable

[Brian Goetz]

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.)