http://d.puremagic.com/issues/show_bug.cgi?id=10670
--- Comment #3 from [email protected] 2013-07-22 03:21:52 PDT --- I've done the dev. Here is my preliminary experience with it: For starters, there *is* some convenience in using "front as seed" for calls such as: //---- double[] a = [ 3, 4, 7, 11, 3, 2, 5 ]; // Compute minimum and maximum in one pass auto r = reduce!(min, max)(a); //---- Here, even a straight up "0.0" is a bad seed. The code needs to be fixed as: //---- double[] a = [ 3, 4, 7, 11, 3, 2, 5 ]; // Compute minimum and maximum in one pass auto r = reduce!(min, max)(tuple(double.max, double.min), a); //---- Not very convenient. But still, nothing surmountable. But at the same time, if you look at the existing unittests, you can see some strange things such as: //---- // two funs auto r2 = reduce!("a + b", "a - b")(tuple(0.0, 0.0), a); writeln(r2); assert(r2[0] == 7 && r2[1] == -7); auto r3 = reduce!("a + b", "a - b")(a); assert(r3[0] == 7 && r3[1] == -1); //---- I don't know what that was trying to prove, but it shows that no-seed can do some really strange things. The "assert not float (or char for that matter)" was very efficient in catching float seeds, and catched almost all of the "wrong usage" cases. The only one that it did not catch was the above case. But such code doesn't make sense to me. I think "silent breakage" would really be minimal. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
