Feasible Idea?: Range Tester

[Jonathan M Davis]

On Friday, March 22, 2013 09:37:32 timotheecour wrote:
> > it would have to be agreed upon
> > whether assertions should be used or whether RangeError should
> > be used (or
> > that using either was valid, though that's a bad idea IMHO).
> 
> if we force range code to throw RangeError, wouldn't that prevent
> optimization in release mode? If so, that's no good. Also, simply
> using assert(...); is much more convenient in lots of cases
> (think user written ranges that don't wanna be bogged down by
> boilerplate).
> So why not just say: only AssertError or RangeError are valid in
> that case, that doesn't seem controversial.

My main point was that it makes no sense to test for standard behavior if that 
standard behavior hasn't been agreed upon.

My secondary point was that I think that it's a very bad idea to try and 
"standardize" the behavior an then let do different things depending on what 
the programmer felt like.

In this particular situation, I think that I'd favor an assertion, but 
regardless, the way that we've been using RangeError in Phobos is in a 
version(assert) block, so they wouldn't even be enabled with -release anyway. 
And I question that it makes sense to test a type to make sure that it asserts 
something, which is basically what we'd be doing if we verifying that an 
AssertError (or a RangeError without -release) was thrown when calling 
popFront on an empty range. We just treat that sort of thing as undefined 
behavior.

So, I really don't think that it makes any sense to test for how a range 
behaves when you call popFront on it when it's empty.

- Jonathan M Davis