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
