Functional vs simple code

[jerro]

> While fiddling with this I came across something that seems odd 
> in the behaviour of reduce and wondered if it's intended. It 
> rather limits the usefulness of reduce with UFCS to "a + b" and 
> "a - b".
>
> Reduce works correctly when provided with a seed argument:
>
> reduce!"a + b + 2"(0, [1,1,1]).writeln; // == 9 as expected
>
> With UFCS I see no elegant way to reduce a chain with a more 
> sophisticated reduce argument than the two simple ones listed 
> above because the operation is not carried out on the first 
> array element, used as the seed. This means:
>
> [1,1,1].reduce!"a + b + 2".writeln; // == 7
>
> which is useless and could easily trip people up because the 
> intuitive expectation is that it will act like the seed 
> example. If I am wrong in that expectation what is a use case 
> for the seedless behaviour?

The fact that it does something different than the seeded version 
does not make the seedless version useless - in fact, that's what 
makes it useful. A typical use case is to find the maximum of a 
range (there is an example of this in the documentation at 
http://dlang.org/phobos/std_algorithm.html#reduce). If you don't 
know the highest possible value of elements, then you couldn't 
come up with an appropriate seed for this case.

I agree that the difference between the two versions of reduce 
can be a bit confusing. Maybe it would be better if they were 
named differently.

> Is there a way of writing the operation to give the same answer 
> as the seed answer?

In general, no (apart from the silly reduce!f(chain([seed], 
range))). If you want the behavior of the seeded version, use the 
seeded version.

> The element in position 0 should surely have +2 added to 
> itself, it's only being the seed out of convenience isn't it?

No, reduce!f(r) is not merely a syntactic sugar for reduce!f(0, 
r) (you could say it's a syntactic sugar for reduce!f(r.front, 
r.drop(1), though). Making reduce!f(r) be the same as reduce!f(0, 
r) doesn't really make any sense - would you expect [1, 2, 
3].reduce!"a * b" to return 0?  I wouldn't.

> Instead we get 1 + (1 + 2) + (1 + 2). The order of reduce's 
> arguments, (seed, range) prevent it being used with UFCS 
> properly. If it were (range, seed) then there would be no 
> problem:
>
> [1,1,1].reduce!"a + b + 2"(0).writeln; // == 9

This would be better, yes. Reduce was written before there was 
UFCS, so they couldn't take this into account. I don't know if it 
is possible for this to be changed now, as it would definitely 
break some code.