Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

[Peter Levart]

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.
>