On 3/12/19 5:04 PM, Brian Goetz wrote:
No. You have the LSP backwards (though this is easy to do.)

IterableOnce means "*must throw* on subsequent use"; under this spec, an arbitrary Iterable is most certainly *not* an IterableOnce, and therefore an LSP violation.

It sounds like you are suggesting that we instead spec IterableAtLeastOnce, of which Iterable *would* be a credible subtype -- but due to how Iterable is specified now, the problem is that Iterable *already is* really "iterable at least once."  So there would be no point in introducing this type; we already have it.

Due to how Iterable is specified now it does not promise multiple iterations, but due to how most (all that I know of except DirectoryStream or some 3rd party) Iterables are implemented now, the common expectation is that it does. By implementing more Iterable(s) that don't support multiple iteration (regardless of whether they implement this new sub-type or not), this expectation will be less and less honored. Perhaps this is not so bad. At various occasions the specification has been changed to accommodate the long-standing behavior or expectation of behavior, but this seems not to be one of them.

Let's pretend for a moment that Iterable specification was changed to guarantee multi-pass iteration. In that case the IterableAtLeastOnce as a supertype of multi-pass Iterable would make much more sense, wouldn't it?

But as there could be Iterables out there that by current spec are perfectly valid and don't support multi-pass iteration, such spec change would make them non-conformant and is therefore not allowed. So I'm convinced now that this is the least-bad solution.

Regards, Peter



If we were doing this from scratch, we might choose a different path, but that option is not open to us.  As several have already noted, this proposal is not ideal, but due to the corner we're painted into by Iterable's current spec, there is not going to be an ideal outcome -- and the current strategy (do nothing) is also not ideal and makes many people unhappy.  So the game here is finding the least-bad solution that is compatible with the constraints we have, which I think Stuart has done exactly. (Also, he did a very nice job of writing up all the alternatives, to avoid (or at least reduce) the torrent of "have you thought about <thing that has been thought about extensively>".)

On 3/6/2019 10:50 AM, Peter Levart wrote:

In this respect Iterable should be a subtype of IterableOnce and foreach loop should be retrofitted to work with IterableOnce.


Reply via email to