Should reduce take range as first argument?

[Timon Gehr]

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)