[Issue 10670] std.algorithm.reduce: no-seed initialization wrong design
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Fri Jul 19 08:07:58 PDT 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10670
hsteoh at quickfur.ath.cx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hsteoh at quickfur.ath.cx
--- Comment #2 from hsteoh at quickfur.ath.cx 2013-07-19 08:07:58 PDT ---
I've run into this issue before. I agree that if no seed value is provided, it
should use ElementType!range.init, NOT range.front.
In the case of floats, well... I'd argue that using the seedless variety of
reduce on a float range is already a bug, so it should be fixed anyway.
Alternatively, since float.init is always NaN, it makes no sense to use the
seedless variety of reduce, so we could just static assert(false) if
isFloatingPointType!(ElementType!range). This will break existing code but at
least it will point out why the code is breaking, instead of silently changing
whatever the current behaviour is.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
More information about the Digitalmars-d-bugs
mailing list