The lack of indexing for foreach and ranges is a bit of problem (not a huge one but definitely an annoying one - it's one of the few reasons to still use opApply instead of ranges). The obvious solution is to just have the compiler provide a counter. So,

foreach(i, e; range)
{
 //code
}

gets lowered to something like

foreach(size_t i = 0; !range.empty; ++i, range.popFront())
{
 auto e = range.front;
 //code
}

But as I understand it, some have been opposed to that idea due to ranges which might have more exotic iteration schemes. If that's the case, would it make sense to do the above but then allow for ranges which returned their next index from popFront? i.e.

foreach(size_t i = 0; !range.empty; i = range.popFront())
{
 auto e = range.front;
 //code
}

So, in the rare cases where a more control of the iteration scheme is desirable, instead of being void, popFront would return size_t where that size_t is the next index. Is there a reason why this wouldn't do the trick?

I think that we'd definitely benefit by allowing the first case regardless, but if the second solves the problem of the index not being flexible enough, then presumably that would make this solution for indexing with ranges more acceptable.

Thoughts? Is there anything obvious (or non-obvious) that I'm missing here?

- Jonathan M Davis

Jonathan M Davis:

> The lack of indexing for foreach and ranges is a bit of problem (not a huge
> one but definitely an annoying one - it's one of the few reasons to still use
> opApply instead of ranges). The obvious solution is to just have the compiler
> provide a counter.
> ...
> Thoughts? Is there anything obvious (or non-obvious) that I'm missing here?

Time ago I have proposed this, I think this is a tidier solution, that requires no compiler changes: http://d.puremagic.com/issues/show_bug.cgi?id=5550

(and then the front-end is free to recognize the usage of this Phobos range enumerate(), and optimize it much better).

Usage example (this also uses the tuple unpacking syntax):

foreach ((i, e); enumerate(range)) {
    // code that uses i and e
}


Until the tuple unpacking syntax is not present you use:

foreach (ie; enumerate(range)) {
    const i = ie[0];
    const e = ie[1];
    // code that uses i and e
}

Bye,
bearophile

2012/1/24 bearophile <bearophileHUGS@lycos.com>:
> Jonathan M Davis:
>
>> The lack of indexing for foreach and ranges is a bit of problem (not a huge
>> one but definitely an annoying one - it's one of the few reasons to still use
>> opApply instead of ranges). The obvious solution is to just have the compiler
>> provide a counter.
>> ...
>> Thoughts? Is there anything obvious (or non-obvious) that I'm missing here?
>
> Time ago I have proposed this, I think this is a tidier solution, that requires no compiler changes: http://d.puremagic.com/issues/show_bug.cgi?id=5550
>
> (and then the front-end is free to recognize the usage of this Phobos range enumerate(), and optimize it much better).
>
> Usage example (this also uses the tuple unpacking syntax):
>
> foreach ((i, e); enumerate(range)) {
>    // code that uses i and e
> }
>
>
> Until the tuple unpacking syntax is not present you use:
>
> foreach (ie; enumerate(range)) {
>    const i = ie[0];
>    const e = ie[1];
>    // code that uses i and e
> }
>
> Bye,
> bearophile

Today, foreach can expand the front tuple automatically.

foreach (i, e; zip(sequence!"n", range))
{
    // i = 0, 1, 2, ...
    // e = elements of range
}

So extra unpacking syntax is not need.

Kenji Hara

kenji hara:

> Today, foreach can expand the front tuple automatically.
> 
> foreach (i, e; zip(sequence!"n", range))
> {
>     // i = 0, 1, 2, ...
>     // e = elements of range
> }
> 
> So extra unpacking syntax is not need.

Very good, I didn't know it. This works:

import std.stdio, std.range, std.algorithm;
void main() {
    auto range = [1, 2, 3, 4];
    foreach (i, e; zip(sequence!"n"(), range))
        writeln(i, " ", e);
}


So it's better to update the zip usage example in the docs: http://www.dlang.org/phobos/std_range.html#zip

That currently is (plus newlines that don't get copied in copying&pasting from the site pages):
int[] a = [ 1, 2, 3 ]; string[] b = [ "a", "b", "c" ]; // prints 1:a 2:b 3:c foreach (e; zip(a, b)) { write(e[0], ':', e[1], ' '); }


But going against what Walter usually says, some shallow higher order functions are not useless in Phobos, so:
enumerate(range)
is quite better than this for programmers:
zip(sequence!"n"(), range)
(And maybe it's simpler for a D front-end to recognize the enumerate() and optimize it better).

Bye,
bearophile

> import std.stdio, std.range, std.algorithm;
> void main() {
>     auto range = [1, 2, 3, 4];
>     foreach (i, e; zip(sequence!"n"(), range))
>         writeln(i, " ", e);
> }

But I was talking about tuple unpacking, not typetuple unpacking:


import std.stdio, std.range, std.algorithm, std.typecons;
alias Tuple!(int,int) P;
void main() {
    auto ap = [P(1,2), P(3,4), P(5,6)];
    foreach ((x, y); ap)  // <== std.typecons.tuple unpacking
        writeln(x, " ", y);
}

Bye,
bearophile

On 1/23/12 6:40 PM, kenji hara wrote:
> Today, foreach can expand the front tuple automatically.
>
> foreach (i, e; zip(sequence!"n", range))
> {
>      // i = 0, 1, 2, ...
>      // e = elements of range
> }
>
> So extra unpacking syntax is not need.
>
> Kenji Hara

That's awesome! Walter mentioned you made that addition. Is there some precise documentation to it?

Thanks,

Andrei

2012/1/24 bearophile <bearophileHUGS@lycos.com>:
>> import std.stdio, std.range, std.algorithm;
>> void main() {
>>     auto range = [1, 2, 3, 4];
>>     foreach (i, e; zip(sequence!"n"(), range))
>>         writeln(i, " ", e);
>> }
>
> But I was talking about tuple unpacking, not typetuple unpacking:

std.range.zip makes a range of std.typecons.Tuple, not std.typetuple.TypeTuple. Then foreach statement supports the std.typecons.Tuple unpacking of range.front.

> import std.stdio, std.range, std.algorithm, std.typecons;
> alias Tuple!(int,int) P;
> void main() {
>    auto ap = [P(1,2), P(3,4), P(5,6)];
>    foreach ((x, y); ap)  // <== std.typecons.tuple unpacking
>        writeln(x, " ", y);
> }

Therefore, follows would work.

    auto ap = [P(1,2), P(3,4), P(5,6)];
    foreach (x, y; ap)  //
        writeln(x, " ", y);

Kenji Hara

Precise documentation is not yet written. The original issue is http://d.puremagic.com/issues/show_bug.cgi?id=6366

Kenji Hara

2012/1/24 Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
> On 1/23/12 6:40 PM, kenji hara wrote:
>>
>> Today, foreach can expand the front tuple automatically.
>>
>> foreach (i, e; zip(sequence!"n", range))
>> {
>>     // i = 0, 1, 2, ...
>>     // e = elements of range
>> }
>>
>> So extra unpacking syntax is not need.
>>
>> Kenji Hara
>
>
> That's awesome! Walter mentioned you made that addition. Is there some precise documentation to it?
>
> Thanks,
>
> Andrei

kenji hara:

> std.range.zip makes a range of std.typecons.Tuple, not std.typetuple.TypeTuple. Then foreach statement supports the std.typecons.Tuple unpacking of range.front.

Ah, right.


> Therefore, follows would work.
> 
>     auto ap = [P(1,2), P(3,4), P(5,6)];
>     foreach (x, y; ap)  //
>         writeln(x, " ", y);

This program:

import std.stdio, std.range, std.algorithm, std.typecons;
alias Tuple!(int,int) P;
void main() {
    auto ap = [P(1,2), P(3,4), P(5,6)];
    foreach (x, y; ap)
        writeln(x, " ", y);
}

To me outputs:

0 Tuple!(int,int)(1, 2)
1 Tuple!(int,int)(3, 4)
2 Tuple!(int,int)(5, 6)

Instead of:

1 2
3 4
5 6

If you have an array, foreach puts the index of the items at the first variable.

To tell apart tuple unpacking from normal array indexing I have suggested a syntax like:
foreach ((x, y); ap)
If you fear programmers will miss the (), then requiring something like an auto solves the problem:
foreach (auto (x, y); ap)

Bye,
bearophile

Ok, I understand.

The syntax is similar to my "multiple var declaration" proposal. http://d.puremagic.com/issues/show_bug.cgi?id=6365 https://github.com/D-Programming-Language/dmd/pull/341

If the enhancement would be accepted, I'd like to implement your proposal to increase consistency.

Kenji Hara

2012/1/24 bearophile <bearophileHUGS@lycos.com>:
> kenji hara:
>
>> std.range.zip makes a range of std.typecons.Tuple, not std.typetuple.TypeTuple. Then foreach statement supports the std.typecons.Tuple unpacking of range.front.
>
> Ah, right.
>
>
>> Therefore, follows would work.
>>
>>     auto ap = [P(1,2), P(3,4), P(5,6)];
>>     foreach (x, y; ap)  //
>>         writeln(x, " ", y);
>
> This program:
>
> import std.stdio, std.range, std.algorithm, std.typecons;
> alias Tuple!(int,int) P;
> void main() {
>    auto ap = [P(1,2), P(3,4), P(5,6)];
>    foreach (x, y; ap)
>        writeln(x, " ", y);
> }
>
> To me outputs:
>
> 0 Tuple!(int,int)(1, 2)
> 1 Tuple!(int,int)(3, 4)
> 2 Tuple!(int,int)(5, 6)
>
> Instead of:
>
> 1 2
> 3 4
> 5 6
>
> If you have an array, foreach puts the index of the items at the first variable.
>
> To tell apart tuple unpacking from normal array indexing I have suggested a syntax like:
> foreach ((x, y); ap)
> If you fear programmers will miss the (), then requiring something like an auto solves the problem:
> foreach (auto (x, y); ap)
>
> Bye,
> bearophile