Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams
peter.levart at gmail.com
Tue Mar 12 17:34:58 UTC 2019
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.
> 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
> 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.
More information about the core-libs-dev