For me, the idea of adding an
Iterable protocol for possibly single-pass sequences falls apart when we consider exactly what it looks like. Let’s assume we add it, and now any
Iterable type can be iterated using a
in loop. Is that all the protocol does? Seems like it would be pretty useful to iterate over an
Iterable and transform each element in some way, right? So let’s move
Sequence down to
Iterable. What if we want to add up all the values in an
Iterable of integers? Better move
reduce down, too. And so it goes with everything on
Sequence right now, and you’re back where you started. I have traveled down this road many times, and no matter which of the requirements I’m questioning, I’ve always ended up at the same place.
Sequence has its particular semantics, the methods you define can also have their own preconditions. For example, the
Sequence protocol doesn’t guarantee finite-ness, but plenty of sequence methods (
reduce, etc) require that the subject be finite. So two possible options, then, are to require one of the two inputs of the cartesian product to be a
Collection, or on the other hand to let them both be sequences but document the method with the requirement that one of them “yield the same elements on every iteration” or something.