digitalmars.D.bugs - [Issue 15357] New: Cannot call std.algorithm.iteration.each on the
- via Digitalmars-d-bugs (41/41) Nov 18 2015 https://issues.dlang.org/show_bug.cgi?id=15357
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. --
Nov 18 2015