On Tuesday, 25 March 2014 at 17:22:45 UTC, monarch_dodra wrote:
I'm working on something called "fold". It is designed as
nothing more than a replacement for "reduce", but where the
seed comes *second* in terms of arguments. It allows this:
someLongUFCSChain().reduce(intoThis);
It might not look like this, but it is a *constant* source of
nuisance. In particular, chains that start out like this:
someLongUFCSChain().reduce();
Need to be changed into this to add a seed:
reduce(someLongUFCSChain(), intoThis);
After a couple of tries to "swap" the arguments, it was
observed that it simply couldn't be done wihthout silent
run-time breakage. So that was not acceptable.
The solution: Re-introduce "reduce" under a new name: "fold".
Simple as that.
--------
I'm taking this naming-changing event as an opportunity to
"cleanup" reduce too. One thing that gets on my nerves is that
"range.reduce()" is not nothrow, because it throws an exception
if the range is empty.
I think this is wrong. popping an empty range is an *Error*,
and should be validated by the programmer. Because of this, it
is currently not possible to use "reduce(range)" in nothrow
context.
This however, even with a name change, it *is* change of
behavior. Do you feel this is acceptable? Do you want this
change at all? Or do you think an Exception is fine?
Sounds to me like the fact that it throws an Exception instead of
an Error is a leftover from the earlier days of ranges, when it
wasn't clear what one should do in the case of an empty range. I
think it's well worth making fold nothrow, and it will simplify
calling code in the case where the callee wrapped reduce in a
try-catch block.