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.