enhanced for loop with multiple iteration variables

[Remi Forax]

----- Mail original -----
> De: "Alan Snyder" <javalists at cbfiddle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Vendredi 21 Décembre 2018 03:19:14
> Objet: Re: enhanced for loop with multiple iteration variables

> RIght, but I don’t see that as a general solution.
> 
> Its also a bit kludgy, like saying that methods need only one parameter because
> you can always pass a data object.

yes, that's the point, as part of Valhalla, we want to introduce value types in Java.
A value type is an almost zero cost abstraction that let you group and ungroup values.

Also as part of Amber, we want to be able to de-construct record types (product types) in order to support pattern matching.

If we have value types and de-construction, we are not far be able to write something like:
  for((var key, var value): map.entrySet()) {
    // ...
  }
with no runtime cost.

So being able to use the enhanced for loop on tuples is clearly something we want to have, but to achieve that goal i don't think that introducing a new Iterator2 interface is the right way to do that.

regards,
Rémi


> 
>> On Dec 20, 2018, at 2:50 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>> For Map, you can do:
>> 
>>     for (Map.Entry<K,V> e : map.entrySet()) { ... }
>> 
>> and you're already there.
>> 
>> 
>> 
>> On 12/19/2018 9:54 AM, Alan Snyder wrote:
>>> Has any consideration been given to supporting iterators that provide more than
>>> one iteration variable in the enhanced for loop?
>>> 
>>> Obvious uses would be maps (keys and values) and lists (indexes and values).
>>> 
>>> I have in mind keeping the syntactic sugar approach by using one or more
>>> extensions of the Iterator/Iterable interfaces, such as, for example:
>>> 
>>> interface Iterator2<E1,E2> extends Iterator<E1> {
>>>   E2 get2();
>>> }
>>> 
>>> with the extra methods providing the values for the extra variables (associated
>>> with the previous call to next).
>>> 
>>> Extending interfaces is not required, but it makes the trailing variables
>>> optional, which might be useful. For example, the same iterator could provide
>>> values or values and keys.
>>> 
>>> The fact that this approach only works for a fixed set of numbers of variables
>>> does not bother me unduly.
>>> 
>>>   Alan
>>>