> 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.

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

On Thursday, March 21, 2013 22:03:25 Nick Sabalausky wrote:
> On Thu, 21 Mar 2013 21:55:10 -0400
> 
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote:
> > Anything else would be a change that would
> > have to be discussed, so specifically testing that a conformant range
> > throws a RangeError from popFront when it's empty (as Nick was
> > suggesting) would not be correct at this point.
> 
> I wasn't suggesting that, merely trying to list a bunch of examples of testable things. Clearly I got a few of the examples wrong ;)

You were suggesting it in the sense that you listed it as something to test for, not that you were proposing it.

> But that does kinda speak to the usefulness of having something standard that can be expected to actually do the *correct* tests, instead of all range authors just winging it on their own and potentially misunderstanding the rules.

Yes, though some of those are really undefined behavior (e.g. what happens when you call popFront on an empty range), so it wouldn't really make sense to test them. But having ways to test for standard behavior would make it easier to ensure that that behavior is actually standard.

- Jonathan M Davis

On 3/21/2013 7:03 PM, Nick Sabalausky wrote:
> But that does kinda speak to the usefulness of having something
> standard that can be expected to actually do the *correct* tests,
> instead of all range authors just winging it on their own and
> potentially misunderstanding the rules.

I agree.