phobos commit, revision 1871


user: dsimcha

msg:
Added Lockstep, hasLvalueElements.

http://www.dsource.org/projects/phobos/changeset/1871

I've added Lockstep to std.range, which allows things like:

foreach(a, b; lockstep(range1, range2)) {
     // Loop body.
}

If anyone really doesn't like it, it can be removed, but I've **really** wanted this functionality for a **long** time.

I considered integrating it into Zip, but decided against this because:

1.  DMD doesn't currently work properly in terms of overloading opApply-based foreach against range-based foreach, even when there is no ambiguity.

2.  Even if this gets fixed, there will still be ugly ambiguous cases if iterating with Proxy and iterating as individual variables are put in the same struct once bug 3444 (http://d.puremagic.com/issues/show_bug.cgi?id=3444) gets fixed.

Using Zip for iterating in lockstep over ranges via foreach is just syntactically ugly enough that I never do it in practice.  This is mostly because I can't name the element variables individually and have to access them as members of a Proxy.  Zip has its place for things like sorting in lockstep, and I plan to improve/debug it, too, but I really felt that for simple foreach-based lockstep iteration, a separate struct was necessary.

On 8/15/2010 5:26 PM, dsource.org wrote:
> phobos commit, revision 1871
>
>
> user: dsimcha
>
> msg:
> Added Lockstep, hasLvalueElements.
>
> http://www.dsource.org/projects/phobos/changeset/1871
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
> 

On Sunday 15 August 2010 14:31:28 David Simcha wrote:
> I've added Lockstep to std.range, which allows things like:
> 
> foreach(a, b; lockstep(range1, range2)) {
>      // Loop body.
> }
> 
> If anyone really doesn't like it, it can be removed, but I've **really** wanted this functionality for a **long** time.
> 
> I considered integrating it into Zip, but decided against this because:
> 
> 1.  DMD doesn't currently work properly in terms of overloading opApply-based foreach against range-based foreach, even when there is no ambiguity.
> 
> 2.  Even if this gets fixed, there will still be ugly ambiguous cases if iterating with Proxy and iterating as individual variables are put in the same struct once bug 3444 (http://d.puremagic.com/issues/show_bug.cgi?id=3444) gets fixed.
> 
> Using Zip for iterating in lockstep over ranges via foreach is just syntactically ugly enough that I never do it in practice.  This is mostly because I can't name the element variables individually and have to access them as members of a Proxy.  Zip has its place for things like sorting in lockstep, and I plan to improve/debug it, too, but I really felt that for simple foreach-based lockstep iteration, a separate struct was necessary.

The situation where you have to iterate over two separate ranges at the same time has always been a flaw in foreach that has irritated me (in any language that I've used). I haven't found it to be that big a deal, since you just turn it into a for loop, make it a bit more verbose, and you're fine, but being able to iterate over two ranges simultaneously with foreach would be a good thing. This looks like a good addition to Phobos.

- Jonathan M Davis