On 05/14/2012 11:33 PM, Andrei Alexandrescu wrote:
On 5/14/12 4:10 PM, Justin Whear wrote:
In its current form, std.algorithm.reduce takes optional seed value(s)
for the accumulator(s) as its first argument(s). This breaks the nice
chaining effect made possible by UFCS:
Works:
-----------------------------------------
auto foo = reduce!((string s, string x) => s ~= x)("BLAH", args.map!(x =>
x[1..$-1]));
-----------------------------------------
Doesn't work, but looks much nicer:
-----------------------------------------
auto foo = args.map!(x => x[1..$-1]))
.reduce!((string s, string x) => s ~= x)("BLAH");
-----------------------------------------
This could be fixed with a breaking change by making the subject range to
be the first parameter. Aside from breaking existing code, are there
other obstacles to changing this?
Justin Whear
Yah, reduce was not designed for the future benefit of UFCS. (I recall
take() was redefined towards that vision, and it was a good move.)
We can actually deprecate the current order and accept both by inserting
the appropriate template constraints. We change the documentation and
examples to reflect the new order, and we leave a note saying that the
old order is deprecated. We can leave the deprecated version in place
for a long time. Thoughts?
Andrei
Just as for take, the new order is backwards. I don't know what to do
about it though.
Also, what would be the deprecation path for reduction of a range of
this form:
class Foo{
Foo front();
bool empty();
void popFront();
}
:o)
