digitalmars.D - Ranges and indexes with foreach
- "Jonathan M Davis" <jmdavisProg gmx.com> Jan 23 2012
- bearophile <bearophileHUGS lycos.com> Jan 23 2012
- Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Jan 23 2012
- Denis Shelomovskij <verylonglogin.reg gmail.com> Jan 24 2012
- kenji hara <k.hara.pg gmail.com> Jan 23 2012
- bearophile <bearophileHUGS lycos.com> Jan 23 2012
- bearophile <bearophileHUGS lycos.com> Jan 23 2012
- kenji hara <k.hara.pg gmail.com> Jan 23 2012
- bearophile <bearophileHUGS lycos.com> Jan 23 2012
- kenji hara <k.hara.pg gmail.com> Jan 23 2012
- kenji hara <k.hara.pg gmail.com> Jan 23 2012
- bearophile <bearophileHUGS lycos.com> Jan 23 2012
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
Jan 23 2012
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
Jan 23 2012
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
Jan 23 2012
24.01.2012 5:50, kenji hara пишет:Precise documentation is not yet written.
Filled an issue: http://d.puremagic.com/issues/show_bug.cgi?id=7361
Jan 24 2012
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 h=
one but definitely an annoying one - it's one of the few reasons to stil=
opApply instead of ranges). The obvious solution is to just have the com=
provide a counter. ... Thoughts? Is there anything obvious (or non-obvious) that I'm missing he=
Time ago I have proposed this, I think this is a tidier solution, that re=
http://d.puremagic.com/issues/show_bug.cgi?id=3D5550 (and then the front-end is free to recognize the usage of this Phobos ran=
Usage example (this also uses the tuple unpacking syntax): foreach ((i, e); enumerate(range)) { =A0 =A0// code that uses i and e } Until the tuple unpacking syntax is not present you use: foreach (ie; enumerate(range)) { =A0 =A0const i =3D ie[0]; =A0 =A0const e =3D ie[1]; =A0 =A0// code that uses i and e } Bye, bearophile
Today, foreach can expand the front tuple automatically. foreach (i, e; zip(sequence!"n", range)) { // i =3D 0, 1, 2, ... // e =3D elements of range } So extra unpacking syntax is not need. Kenji Hara
Jan 23 2012
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
Jan 23 2012
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
Jan 23 2012
2012/1/24 bearophile <bearophileHUGS lycos.com>:import std.stdio, std.range, std.algorithm; void main() { =A0 =A0 auto range =3D [1, 2, 3, 4]; =A0 =A0 foreach (i, e; zip(sequence!"n"(), range)) =A0 =A0 =A0 =A0 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.TypeTu= ple. Then foreach statement supports the std.typecons.Tuple unpacking of range.f= ront.import std.stdio, std.range, std.algorithm, std.typecons; alias Tuple!(int,int) P; void main() { =A0 =A0auto ap =3D [P(1,2), P(3,4), P(5,6)]; =A0 =A0foreach ((x, y); ap) =A0// <=3D=3D std.typecons.tuple unpacking =A0 =A0 =A0 =A0writeln(x, " ", y); }
Therefore, follows would work. =A0 =A0auto ap =3D [P(1,2), P(3,4), P(5,6)]; =A0 =A0foreach (x, y; ap) =A0// =A0 =A0 =A0 =A0writeln(x, " ", y); Kenji Hara
Jan 23 2012
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
Jan 23 2012
Precise documentation is not yet written. The original issue is http://d.puremagic.com/issues/show_bug.cgi?id=3D6366 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)) { =A0 =A0 // i =3D 0, 1, 2, ... =A0 =A0 // e =3D 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
Jan 23 2012
Ok, I understand. The syntax is similar to my "multiple var declaration" proposal. http://d.puremagic.com/issues/show_bug.cgi?id=3D6365 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.Typ=
Then foreach statement supports the std.typecons.Tuple unpacking of rang=
Ah, right.Therefore, follows would work. =A0=A0 =A0auto ap =3D [P(1,2), P(3,4), P(5,6)]; =A0=A0 =A0foreach (x, y; ap) =A0// =A0=A0 =A0 =A0 =A0writeln(x, " ", y);
This program: import std.stdio, std.range, std.algorithm, std.typecons; alias Tuple!(int,int) P; void main() { =A0 =A0auto ap =3D [P(1,2), P(3,4), P(5,6)]; =A0 =A0foreach (x, y; ap) =A0 =A0 =A0 =A0writeln(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 va=
To tell apart tuple unpacking from normal array indexing I have suggested=
foreach ((x, y); ap) If you fear programmers will miss the (), then requiring something like a=
foreach (auto (x, y); ap) Bye, bearophile
Jan 23 2012
kenji hara:If the enhancement would be accepted, I'd like to implement your proposal to increase consistency.
Thank you :-) And as you say it's wiser to wait to see if Walter&Andrei appreciate what you have already done, first, efore working further on this. Bye, bearophile
Jan 23 2012









Denis Shelomovskij <verylonglogin.reg gmail.com> 