On 06/28/2013 03:19 PM, Joseph Rushton Wakeling wrote:
> Consider the following equivalent code using zip and lockstep respectively to iterate over the entries in an array and set their values:
> 
>     auto arr1 = new double[10];
>     foreach(i, ref x; zip(iota(10), arr1))
>     {
>         x = i;
>     }
>     writeln(arr1);
> 
>     auto arr2 = new double[10];
>     foreach(i, ref x; lockstep(iota(10), arr2))
>     {
>         x = i;
>     }
>     writeln(arr2);
> 
> The first array will still be full of nan's when it is output, while the second will have values set correctly.  Can anyone offer a reasonable explanation why this should be so?  It looks like a bug to me, or at best an unreasonable difference in functionality. :-(

... ping ...?

The particular motivation here is bearophile's proposal to deprecate lockstep in
favour of zip:
http://d.puremagic.com/issues/show_bug.cgi?id=8155

That's clearly not a viable course until one can 's/lockstep/zip/' and have the altered code Just Work.

I should add that bearophile has been fantastic in suggesting alternative design patterns that don't require either lockstep _or_ zip, but I still think this lockstep/zip discrepancy needs resolving.

On 06/29/2013 11:42 AM, Joseph Rushton Wakeling wrote:
> I should add that bearophile has been fantastic in suggesting alternative design patterns that don't require either lockstep _or_ zip, but I still think this lockstep/zip discrepancy needs resolving.

According to the docs: zip "offers mutation and swapping if all ranges offer it".  But I still get an arrayful of nan's even if I do:

    auto arr3 = new double[10];
    auto index = iota(10).array();
    foreach(i, ref x; zip(index, arr3))
    {
        x = i;
    }
    writeln(arr3);

... even though the array index ought to be mutable here.  Tweaking to

    foreach(ref i, ref x; zip(index, arr3))
    {
       x = i;
    }

... doesn't work either.