First of, it's an SPI that we consume ourselves. We *know* that
need is to iterate, and the "for each" idiom is all we need.
How do you know that? At the moment that might be how it is implemented,
but in the future this might change. In which case Iterable is a very
unthankful data structure to work with.
Also, in many cases some processing can be skipped if I do a simple
empty/size check first. I cannot even do that with an Iterable.
Exposing a List in this case was an error, as it's a leaky
abstraction there is no ordering requirement,
True, so maybe it should have not been a List, but rather a Set of Collection.
Either of them is a better choice than Iterable.
and in fact I was
hoping to replace the implementation with a Set but I couldn't do that
as we committed to a contract which exposes a List.
I am confused? If you are concerned about changing the API, why is the change
to Iterable ok, but not to Set?
There also is a performance aspect. By returning List or Set,
rules require me to wrap them in their immutable counterparts, or make
Shall I come with the premature optimisation argument now?
Many of our internal contracts should be Iterable, especially if
only about iterating _some collection_.