[Issue 8755] Change the order of reduce arguments

[d-bugmail at puremagic.com]

https://d.puremagic.com/issues/show_bug.cgi?id=8755



--- Comment #17 from monarchdodra at gmail.com 2014-03-21 01:51:41 PDT ---
(In reply to comment #14)
> >Furthermore, it also improves usability by making the seeds passed by parameter pack, instead of forcing the use of a tuple.<
> 
> OK. (Despite in a modern language tuples should be built-in, so using them
> should be natural, common, and syntactically very cheap. In
> Python/Haskell/Scala code you don't see functions that refrain from accepting a
> tuple).

The current most spread phobos style is to accept arguments via vararg, and to
return tuples when you need to return several args, so I tried to stick to
that.

I'm not sure it is possible to accept either a Tuple (that "auto expands"
later), and varargs, without potentially creating some ambiguity.

> >Finally, it allows using only 1 seed, in which case, the same seed is replicated and is used for all the functions.
> 
> This is from the unittests:
> 
>     // Compute sum and sum of squares in one pass.
>     // This can be used to compute get the average and standard deviation.
>     // A single seed (0.0) is passed, but it is optional
>     // if the range is not empty.
>     r = a.fold!("a + b", "a + b * b")(0.0);
>     assert(approxEqual(r[0], 35));  // sum
>     assert(approxEqual(r[1], 233)); // sum of squares
> 
> This is ambiguous, it seems that "a + b" has a seed while "a + b * b" doesn't
> have a seed. So in my opinion if you give N function then you need to give 0
> seeds, or one N-tuple, or N seeds. So I don't like this.

You think? It made sense to me. I'll have to ask for more input on this. That
said, if we turn it down, then it would be possible to make `Tuple` and
`args...` co-exist as input argument style. EG:

r = a.fold!("a + b", "a + b * b")(0.0, 0.0); //OK!
r = a.fold!("a + b", "a + b * b")(tuple(0.0, 0.0)); //OK! too!

The second one is more verbose, but I see its justified if your seed is already
in the form of a tuple.

So I think you sold me on it.

> >Oh yeah, also, I made it so that when no seed is given, it is an Error to use an empty range. This is the only case of deviation, but I think having nothrow justifies it.
> 
> I am not sure this is a good idea. Throwing when you give no seed is probably
> acceptable. But I am not sure.

It's a deviation, but I think it's justified. It makes the code nothrow, and
quite frankly, accessign an empty range is an Error, so end of story.

The only argument I'd accept in its favor is stability with reduce, but if we
could redesign, I'd never accept throwing an exception in such a case.

> > "iterables" are not supported anymore.
>
> If by "iterables" you mean that fold doesn't accept opApply-based iterables
> then I am against this change, I have plenty of code that opApply-based and I
> sometimes use reduce on them.

OK. I can work them back in.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------