I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

[Ivan Gerasimov]

On 3/15/19 1:51 AM, Peter Levart wrote:
>
>
> On 3/15/19 9:38 AM, Ivan Gerasimov wrote:
>> Hi Peter!
>>
>>
>> On 3/15/19 1:24 AM, Peter Levart wrote:
>>>
>>>
>>> On 3/15/19 9:03 AM, forax at univ-mlv.fr wrote:
>>>>>       * @since 13
>>>>>       */
>>>>>      interface Once {}
>>>>>
>>>>>
>>>>> What do you think of that?
>>>> It's not clear to me if an annotation, available at runtime, is not 
>>>> a better fit.
>>>> Anyway, i'm not sure not sure introducing such interface/annotation 
>>>> worth its maintenance cost, as you said the use case is pretty narrow.
>>>>
>>>
>>> It is narrow, but in a situation like that, where you want to code 
>>> an optimal generic algorithm and all you have access to is an 
>>> Iterable, there's no other way (short of providing additional 
>>> methods, which is ugly). Just think of this situation. You have to 
>>> decide upfront if you need to buffer the elements obtained from 1st 
>>> iteration or not, but 1st iteration always succeeds...
>>>
>> Can you please explain how the interface Once would help to solve this?
>> If an Iterable does not implement Once, it does not mean it allows 
>> multiple passes, right?
>
> It does not guarantee multiple passes, that's right, but that's 
> legacy. This situation is the same for IterableOnce as a subtype of 
> Iterable, but marker interface has less chance to intrude into 
> "visible" static types that consist of method signatures, type 
> parameters and variable types and therefore does not cause confusion 
> in that area.
>
> "Once" is not perfect, but allows generic algorithms to work on those 
> instances that do implement it at least.
>
Thanks for clarifying!
My point was that in the situation you described, an interface Many (or 
MultiPass, or how ever it's named) would be more appropriate.
If an Iterable implements it, there is a guarantee.  Otherwise it has to 
be assumed a one-shot Iterable.

With kind regards,
Ivan


> Regards, Peter
>
>>
>> With kind regards,
>> Ivan
>
>

-- 
With kind regards,
Ivan Gerasimov