• via Digitalmars-d-bugs (41/41) Nov 18 2015 https://issues.dlang.org/show_bug.cgi?id=15357

via Digitalmars-d-bugs <digitalmars-d-bugs puremagic.com> writes:

https://issues.dlang.org/show_bug.cgi?id=15357

          Issue ID: 15357
           Summary: Cannot call std.algorithm.iteration.each on the result
                    of std.range.lockstep
           Product: D
           Version: D2
          Hardware: x86_64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P1
         Component: phobos
          Assignee: nobody puremagic.com
          Reporter: monkeyworks12 hotmail.com

As the result of lockstep only defines an n-array opApply method (where n is
the number of arguments passed to lockstep) and does not conform to the range
interface, it does not properly inter-operate with each, which only works with
ranges. The offending code:

void main(){
  import std.container;
  import std.stdio;
  import std.algorithm.iteration;
  import std.range;

  Array!int ai = [1,2,3,4];
  Array!int ai1 = [1,2,3,4];
  Array!int ai2 = [1,2,3,4];

  auto arange2 = lockstep(ai[],ai1[],ai2[]);

  //Error: template std.algorithm.iteration.each cannot deduce function from
  //argument types !((a, b, c) => writeln(a, b, c))(Lockstep!(RangeT!
  //(Array!int), RangeT!(Array!int), RangeT!(Array!int))), 
  //candidates are:
  //    /opt/compilers/dmd2/include/std/algorithm/iteration.d(820):
  //        std.algorithm.iteration.each(alias pred = "a")
  //arange2.each!((a,b,c) => writeln(a, b, c));
}

Furthermore, it *will* correctly work by accident if the user passes exactly
two ranges where the type of each range's front is convertible to size_t,
because it will interpret the first range as a range of indices.

In my opinion lockstep's opApply should be deprecated outright and replaced
with a range interface that returns a reference to a tuple of its arguments.

--