Bug 10709 – reduce 1-function + no seed, wrong type inference
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
phobos
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-07-23T23:57:27Z
Last change time
2018-02-10T20:06:40Z
Keywords
rejects-valid
Assigned to
monarchdodra
Creator
monarchdodra
Comments
Comment #0 by monarchdodra — 2013-07-23T23:57:27Z
When reduce is not given a seed, it takes the ranges "front" as a first element, however, seed's type should be that of the result of calling "fun".
This is relevent for a function for example, that takes int, and returns a double, or a function that takes operates on const(char)[], and is passed a string: In both case, reduce will error out when trying to store the result (eg double) into the seed (eg int).
What is interesting is that "reduce!fun" gets it wrong, but "reduce!(fun, fun...)" gets it right.
//----
import std.stdio, std.algorithm;
void main(string[] args)
{
{
enum foo = "a + 0.5 * b";
auto r = [0, 1, 2, 3];
//auto r1 = reduce!foo(r); //<-- HERE
auto r2 = reduce!(foo, foo,)(r);
//writeln(r1);
writeln(r2);
}
{
const(char)[] foo(const(char)[], const(char)[]);
string[] r = ["hello", "world"];
//auto r1 = reduce!foo(r); //<-- HERE
auto r2 = reduce!(foo, foo,)(r);
//writeln(r1);
writeln(r2);
}
}
//----
Comment #1 by monarchdodra — 2014-02-25T12:31:08Z
Re-marking myself. Got hit by it with a trivial usecase of summing ubytes: the result is an int, and not assignable to a ubyte.
Should be resolved in my fold fix.
Comment #2 by dlang-bugzilla — 2014-08-16T00:02:15Z