It seems like the consensus here is that, for range primitives, assert()
is the way to go. I'd like to commit the changes in time for the next
release, but I'd like to have Andrei's nod first b/c he's been quiet
throughout this discussion and he's the main designer of std.range and
std.algorithm.
On 8/18/2010 6:49 PM, David Simcha wrote:
While I was debugging std.range and std.algorithm I noticed that
there's tons of inconsistency about when enforce() vs. assert() is
used for checking input to range primitives. I think this needs to be
made consistent, and there are good arguments for both.
enforce() is arguably the way to go because we're dealing with an
external API, not internal consistency checks. According to the
guidelines in TDPL input external to an API should be checked even in
release mode.
On the other hand, assert() is arguably the way to go because ranges
are supposed to be a very efficient abstraction. Having enforce() in
range primitives that look like they should be very fast, inlined
functions is just bad practice. For example, some benchmarks I did
awhile back showed that the use of enforce() and its effect on
inlining can make using ranges slower than using opApply.
Furthermore, if you're stacking several higher-order ranges, i.e.
filter!"a > 0"(map!"a * a"(retro(someArray))) the checks may be
redundant. Lastly, since arrays are the canonical range, omitting
release mode checks in library-defined ranges would make them
consistent with arrays.
Generally when I was debugging I tried to be locally consistent, i.e.
use whatever was used elsewhere in the same range. This meant being
globally inconsistent. Now that I've thought about it, my vote is for
using assert() consistently for range primitives. If ranges are
filled with tons of safety checks that have significant performance
costs and can't be disabled even in release mode, they will have
failed in their goal of providing a lightweight, efficient
abstraction. enforce() can be used for things that are intended to be
called much less frequently, like constructors. Comments?
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
