www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Feasible Idea?: Range Tester

reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
Suppose you create a range: struct MyRange{...}

Now you have to unittest it. And there's a lot of ways a range
implementation can go wrong. There's a fair amount of things to test.
And they all, ideally, need to be done for *every* range type created.

But, ranges are all supposed to conform to a standard interface with
standardized semantics. So can't most of this testing be generalized
into a generic InputRangeTester, RandomAccessRageTester, etc? All you'd
do is feed it an array of elements to test with, and, in theory, it
should be able to unittest the range's semantics for conformance.

Obviously it couldn't guarantee 100% conformance, because no unittest
can do that, but it seems reasonable that it could be just as good as a
well-designed set of hand-written tests.

I think this would be an enormously useful thing to have in Phobos. Can
any Phobos/range gurus say fur sure how feasible this is? Does Phobos
perhaps already do something similar internally that could just be
generalized?

(This message has been brought to you by three random access ranges I
just created but really, really don't feel like unittesting ;) )
Mar 21 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, March 21, 2013 13:08:58 Nick Sabalausky wrote:
 Suppose you create a range: struct MyRange{...}
 
 Now you have to unittest it. And there's a lot of ways a range
 implementation can go wrong. There's a fair amount of things to test.
 And they all, ideally, need to be done for *every* range type created.
 
 But, ranges are all supposed to conform to a standard interface with
 standardized semantics. So can't most of this testing be generalized
 into a generic InputRangeTester, RandomAccessRageTester, etc? All you'd
 do is feed it an array of elements to test with, and, in theory, it
 should be able to unittest the range's semantics for conformance.
 
 Obviously it couldn't guarantee 100% conformance, because no unittest
 can do that, but it seems reasonable that it could be just as good as a
 well-designed set of hand-written tests.
 
 I think this would be an enormously useful thing to have in Phobos. Can
 any Phobos/range gurus say fur sure how feasible this is? Does Phobos
 perhaps already do something similar internally that could just be
 generalized?
 
 (This message has been brought to you by three random access ranges I
 just created but really, really don't feel like unittesting ;) )

Hmmm. I've been working on stuff which makes creating ranges to test range- based functions easier, but I've never thought about creating something to test conformance. If I need something like that I just use static asserts to test isInputRange, isForwardRange, etc. and make sure that each of the ones that are supposed to pass for that range do and that those that aren't supposed to pass don't. All that that's going to test though is the API, not behavior. But I don't know how you'd automate testing behavior when the exact behavior of the range is very much dependent on the range itself. In most cases though, you end up with a new range type, because it's being returned from a range-based function, in which case, simply unit testing the function with a variety of range types generally takes care of it, and those aren't particularly automatable, because what the tests need to test depends entirely on what the function is supposed to do. - Jonathan M Davis
Mar 21 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
21-Mar-2013 21:48, Nick Sabalausky пишет:
 On Thu, 21 Mar 2013 13:29:35 -0400
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote:
 But I don't
 know how you'd automate testing behavior when the exact behavior of
 the range is very much dependent on the range itself.

I don't think that's true at all. Granted, you can't automate testing of the range's internal state, but there's a lot about the external behavior which is very strictly defined: Examples: - Multiple calls to front return the same element. - Calling popFront and then front returns the next element. - If range has length, then 'empty' returns true IFF popFront has been called at least 'myRange.length' times. - Calling popFront doesn't throw unless range is empty. - Calling popFront on an empty range throws a RangeError. - Upon instantiating a new random access range, 'r.front == r[0]', and then after 'r.popFront()', 'r.front == r[1]', etc. - 'r.save.front == r.front'. And then call popFront on both ranges, and 'r1.front == r2.front' is still true. - Iterating via back/popBack yields the same elements as front/popFront, but in reverse order. And I'm sure there's a whole bunch more. If you give a hypothetical generic range-testing tool both an instantiated range to be tested and an array of all the elements you expect to be in the range, in the same order, then I'd think all of the above and more should be testable.

Indeed there is a host of invariants that must hold for any range of certain kind. I'd say this along with other stuff should go into std.test or std.testing (or package within) etc. -- Dmitry Olshansky
Mar 21 2013
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 21 Mar 2013 13:29:35 -0400
"Jonathan M Davis" <jmdavisProg gmx.com> wrote:
 
 But I don't
 know how you'd automate testing behavior when the exact behavior of
 the range is very much dependent on the range itself.

I don't think that's true at all. Granted, you can't automate testing of the range's internal state, but there's a lot about the external behavior which is very strictly defined: Examples: - Multiple calls to front return the same element. - Calling popFront and then front returns the next element. - If range has length, then 'empty' returns true IFF popFront has been called at least 'myRange.length' times. - Calling popFront doesn't throw unless range is empty. - Calling popFront on an empty range throws a RangeError. - Upon instantiating a new random access range, 'r.front == r[0]', and then after 'r.popFront()', 'r.front == r[1]', etc. - 'r.save.front == r.front'. And then call popFront on both ranges, and 'r1.front == r2.front' is still true. - Iterating via back/popBack yields the same elements as front/popFront, but in reverse order. And I'm sure there's a whole bunch more. If you give a hypothetical generic range-testing tool both an instantiated range to be tested and an array of all the elements you expect to be in the range, in the same order, then I'd think all of the above and more should be testable.
Mar 21 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, March 21, 2013 13:52:12 Nick Sabalausky wrote:
 On Thu, 21 Mar 2013 13:48:54 -0400
 
 Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:
 - Calling popFront doesn't throw unless range is empty.
 - Calling popFront on an empty range throws a RangeError.

Actually, I'm not certain about those two, but I know they're true if you just s/popFront/front/

There are no such requirements on ranges. popFront most definitely _can_ throw even if the range is non-empty (e.g. UTFException due to invalid UTF), and I'm not aware of any range in Phobos which currently throws a RangeError when trying to call popFront on an empty range. Normally, an assertion is used, and the range's behavior when popping an element from an empty range in release mode is undefined. But I could definitely see an argument for adopting the policy of having popFront throw RangeError when the range is empty. - Jonathan M Davis
Mar 21 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 23 2013
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 21 March 2013 at 18:19:00 UTC, Jonathan M Davis 
wrote:
 I could definitely see an argument for adopting the
 policy of having popFront throw RangeError when the range is 
 empty.

 - Jonathan M Davis

In release mode, assert expressions are removed. This would not be possible for throwing a RangeError, preventing a useful optimisation in well tested code.
Mar 21 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 21 Mar 2013 13:48:54 -0400
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:
 - Calling popFront doesn't throw unless range is empty.
 - Calling popFront on an empty range throws a RangeError.

Actually, I'm not certain about those two, but I know they're true if you just s/popFront/front/
Mar 21 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 21, 2013 at 01:48:54PM -0400, Nick Sabalausky wrote:
 On Thu, 21 Mar 2013 13:29:35 -0400
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote:
 
 But I don't know how you'd automate testing behavior when the exact
 behavior of the range is very much dependent on the range itself.

I don't think that's true at all. Granted, you can't automate testing of the range's internal state, but there's a lot about the external behavior which is very strictly defined: Examples: - Multiple calls to front return the same element.

This is easy to test.
 - Calling popFront and then front returns the next element.

How do you know if something is the "next element"? What if the range is repeat(1)?
 - If range has length, then 'empty' returns true IFF popFront has been
   called at least 'myRange.length' times.

This should also be easy to test. But it requires the ability to instantiate the range with some given number of elements. So you still need a range-specific function to create the range in the first place.
 - Calling popFront doesn't throw unless range is empty.

Should be easy to check.
 - Calling popFront on an empty range throws a RangeError.

Is this part of the official requirement on ranges? I've been guilty of writing ranges whose popFront are no-ops when the range is empty (simply because for some ranges, it's a pain to explicitly check for this and throw, when the popFront computation doesn't actually assume anything about emptiness).
 - Upon instantiating a new random access range, 'r.front == r[0]', and
   then after 'r.popFront()', 'r.front == r[1]', etc.

This should be relatively easy to check.
 - 'r.save.front == r.front'. And then call popFront on both ranges, and
   'r1.front == r2.front' is still true.

Should be easy to check too. I was gonna say that you'd have to watch out for RNGs, as popFront on an RNG that bases its output on, say, random environmental factors, will break this rule; but on second thought, in this case .save is invalid on such ranges (they can only be input ranges) so this check *should* fail.
 - Iterating via back/popBack yields the same elements as
   front/popFront, but in reverse order.

Doesn't work on infinite ranges. :) (You *can* have infinite ranges with two ends. There's no good reason to do that, of course, because they are effectively just two infinite forward ranges stuck together at their infinite ends, which is kinda pointless, but in theory, this *can* happen.)
 And I'm sure there's a whole bunch more.

 If you give a hypothetical generic range-testing tool both an
 instantiated range to be tested and an array of all the elements you
 expect to be in the range, in the same order, then I'd think all of
 the above and more should be testable.

This wouldn't work on infinite ranges. :) But you could at least test some initial segment of an infinite range, I suppose, so this shouldn't be too big of an issue. T -- Amateurs built the Ark; professionals built the Titanic.
Mar 21 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, March 21, 2013 13:48:54 Nick Sabalausky wrote:
 On Thu, 21 Mar 2013 13:29:35 -0400
 
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote:
 But I don't
 know how you'd automate testing behavior when the exact behavior of
 the range is very much dependent on the range itself.

I don't think that's true at all. Granted, you can't automate testing of the range's internal state, but there's a lot about the external behavior which is very strictly defined: Examples: - Multiple calls to front return the same element. - Calling popFront and then front returns the next element. - If range has length, then 'empty' returns true IFF popFront has been called at least 'myRange.length' times. - Calling popFront doesn't throw unless range is empty. - Calling popFront on an empty range throws a RangeError. - Upon instantiating a new random access range, 'r.front == r[0]', and then after 'r.popFront()', 'r.front == r[1]', etc. - 'r.save.front == r.front'. And then call popFront on both ranges, and 'r1.front == r2.front' is still true. - Iterating via back/popBack yields the same elements as front/popFront, but in reverse order. And I'm sure there's a whole bunch more. If you give a hypothetical generic range-testing tool both an instantiated range to be tested and an array of all the elements you expect to be in the range, in the same order, then I'd think all of the above and more should be testable.

I confess that it pretty much never occurs to me to test most of this stuff. It's always the exact state of the range that I care about, because that has to do with whether the function returns the correct result. But the sort of testing that you're listing here could probably be automated. - Jonathan M Davis
Mar 21 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 21 Mar 2013 11:04:31 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:
 - Calling popFront and then front returns the next element.

How do you know if something is the "next element"? What if the range is repeat(1)?
 - If range has length, then 'empty' returns true IFF popFront has
 been called at least 'myRange.length' times.

This should also be easy to test. But it requires the ability to instantiate the range with some given number of elements. So you still need a range-specific function to create the range in the first place.

What I had in mind was something like: void testForwardRange(R, E)(R range, E[] content) { // Deliberately not contraints, because this *is* a test, after all. // *Or* maybe it just auto-detects range type and leaves it // up to the user to check for "isForwardRange!R" or whatever. static assert(isForwardRange!R); static assert(is(ElementTypeOf!R == E)); static if(hasLength!R) assert(range.length == content.length); foreach(i; 0...content.length) { assert(range.front == content[i]); range.popFront(); } // More tests } unittest{ testForwardRange(createMyRangeSomehow(), [...expected elements...]); }
 
 - Calling popFront on an empty range throws a RangeError.

Is this part of the official requirement on ranges? I've been guilty of writing ranges whose popFront are no-ops when the range is empty (simply because for some ranges, it's a pain to explicitly check for this and throw, when the popFront computation doesn't actually assume anything about emptiness).

Actually, I'm not sure on that one. I would think that calling front on an empty range should throw. Or at least in a typical well-behaved range it should, even if it's not specifically stated as being technically mandatory. But in any case, it was only an example.
 
 - Iterating via back/popBack yields the same elements as
   front/popFront, but in reverse order.

Doesn't work on infinite ranges. :) (You *can* have infinite ranges with two ends. There's no good reason to do that, of course, because they are effectively just two infinite forward ranges stuck together at their infinite ends, which is kinda pointless, but in theory, this *can* happen.)

Naturally, the testing would be different on different types of ranges. The tester could auto-detect things like "isInfiniteRage" and "hasLength", and act accordingly. And of course, if you want to guarantee your range is indeed, for example, a "hasLength", then you can also just add "static assert(hasLength!MyRange);" alongside your call to the tester.
Mar 21 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 21 March 2013 at 17:29:46 UTC, Jonathan M Davis 
wrote:
 Hmmm. I've been working on stuff which makes creating ranges to 
 test range-
 based functions easier, but I've never thought about creating 
 something to
 test conformance.

 - Jonathan M Davis

One of the things I've been trying to deploy is a trait that would help identify *why* a range is (statically) non-compliant. For example, when I was still not 100% up to speed on what it takes for a range to conform to this and that, I'd forget something, and it would take a lot of effort to realize that "dang, my save is not a property, that's why my range is not a random access range". I wrote some traits called things like "assertIsRandomAccessRange!R". Contrary to "assert(isRandomAccessRange!R)", my function would output: "Assertion failed: R is not a random access range because it does not provide the save property". This was quite a helpful tool but... ...It was mostly just code duplication. It would have been an helpful feature, but I'm not sure the code maintenance it entailed in std.range would have made it worth it.
Mar 21 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 21, 2013 at 07:52:32PM +0100, monarch_dodra wrote:
 On Thursday, 21 March 2013 at 17:29:46 UTC, Jonathan M Davis wrote:
Hmmm. I've been working on stuff which makes creating ranges to
test range-
based functions easier, but I've never thought about creating
something to
test conformance.

- Jonathan M Davis

One of the things I've been trying to deploy is a trait that would help identify *why* a range is (statically) non-compliant. For example, when I was still not 100% up to speed on what it takes for a range to conform to this and that, I'd forget something, and it would take a lot of effort to realize that "dang, my save is not a property, that's why my range is not a random access range". I wrote some traits called things like "assertIsRandomAccessRange!R". Contrary to "assert(isRandomAccessRange!R)", my function would output: "Assertion failed: R is not a random access range because it does not provide the save property". This was quite a helpful tool but... ...It was mostly just code duplication. It would have been an helpful feature, but I'm not sure the code maintenance it entailed in std.range would have made it worth it.

I think this is worth doing if you already wrote the templates to do these checks. Ranges are an extremely powerful concept in D, but they are also very obscure for a beginner, and the current error messages don't help. Improving the assertions' messages would be a big improvement, IMO. T -- People tell me I'm stubborn, but I refuse to accept it!
Mar 21 2013
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
 - Upon instantiating a new random access range, 'r.front == r[0]', and
   then after 'r.popFront()', 'r.front == r[1]', etc.

This should be relatively easy to check.

Is that really the behaviour for RA ranges? I'd say that after calling r.popFront(), then r.front == r[0]. The test could be: assert(r has at least two elements); auto nextOne = r[1]; r.popFront(); assert(r.front == nextOne);
Mar 21 2013
prev sibling next sibling parent "jerro" <a a.com> writes:
 void testForwardRange(R, E)(R range, E[] content)
 {
     // Deliberately not contraints, because this *is* a test, 
 after all.
     // *Or* maybe it just auto-detects range type and leaves it
     // up to the user to check for "isForwardRange!R" or 
 whatever.
     static assert(isForwardRange!R);
     static assert(is(ElementTypeOf!R == E));

     static if(hasLength!R)
         assert(range.length == content.length);
 
     foreach(i; 0...content.length)
     {
         assert(range.front == content[i]);
         range.popFront();
     }

     // More tests
 }

Would it make sense to just name the function testRange and have it test conformance for any range primitives that the type supports? Your example already uses static "if(hasLenght!R)" for length, it may be a good idea to expand that.
Mar 21 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 21 Mar 2013 20:24:40 +0100
Philippe Sigaud <philippe.sigaud gmail.com> wrote:

 - Upon instantiating a new random access range, 'r.front == r[0]',
 and then after 'r.popFront()', 'r.front == r[1]', etc.

This should be relatively easy to check.

Is that really the behaviour for RA ranges? I'd say that after calling r.popFront(), then r.front == r[0]. The test could be: assert(r has at least two elements); auto nextOne = r[1]; r.popFront(); assert(r.front == nextOne);

You might be right. See why such a tester would be helpful? ;)
Mar 21 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 21 Mar 2013 21:41:52 +0100
"jerro" <a a.com> wrote:

 void testForwardRange(R, E)(R range, E[] content)
 {
     // Deliberately not contraints, because this *is* a test, 
 after all.
     // *Or* maybe it just auto-detects range type and leaves it
     // up to the user to check for "isForwardRange!R" or 
 whatever.
     static assert(isForwardRange!R);
     static assert(is(ElementTypeOf!R == E));

     static if(hasLength!R)
         assert(range.length == content.length);
 
     foreach(i; 0...content.length)
     {
         assert(range.front == content[i]);
         range.popFront();
     }

     // More tests
 }

Would it make sense to just name the function testRange and have it test conformance for any range primitives that the type supports? Your example already uses static "if(hasLenght!R)" for length, it may be a good idea to expand that.

Possibly. After all, a person really should already be using "static assert(isBlahBlahRange!MyRange);" to make sure their range is the type they expect it to be anyway.
Mar 21 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, March 21, 2013 19:46:08 John Colvin wrote:
 On Thursday, 21 March 2013 at 18:19:00 UTC, Jonathan M Davis
 
 wrote:
 I could definitely see an argument for adopting the
 policy of having popFront throw RangeError when the range is
 empty.
 
 - Jonathan M Davis

In release mode, assert expressions are removed. This would not be possible for throwing a RangeError, preventing a useful optimisation in well tested code.

A valid point as to why such a change in policy should not be made. Regardless, there's definitely no requirement right now that popFront throw RangeError when the range is empty. What Phobos normally does at this point is assert. 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. - Jonathan M Davis
Mar 21 2013
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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 ;) 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.
Mar 21 2013
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, March 22, 2013 08:07:01 timotheecour wrote:
  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


ok what about the following: should work regardless it's RangeError or an assert(0) in th eparticular implementation of a range. ---- bool isThrown(E)(lazy E expression){ import std.exception; import core.exception : RangeError; try expression(); catch(RangeError t) return true; catch(Error t) return true; return false; } unittest(){ int[]x; assert(isThrown(x[1])); } ----

Sure, you could do that, but I'd be completely against putting anything in Phobos to test ranges which tested anything which wasn't agreed upon as the correct way to do it. That being the case, 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). As for the implementation, it would make more sense to simply do assertThrown!Error(x[1]); if you don't care which type of Error is thrown, and if you do care but are allowing both (since you can only give one type to assertThrown), then you could use auto e = collectException!Error(x[1]); assert((cast(AssertError)e) !is null || (cast(RangeError)) !is null); But if you're writing try-catch blocks in unit tests to test exceptions being thrown, odds are that you're not taking proper advantage of std.exception. - Jonathan M Davis
Mar 22 2013
prev sibling parent "timotheecour" <timothee.cour2 gmail.com> writes:
 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.
Mar 22 2013
prev sibling next sibling parent "timotheecour" <timothee.cour2 gmail.com> writes:
  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


ok what about the following: should work regardless it's RangeError or an assert(0) in th eparticular implementation of a range. ---- bool isThrown(E)(lazy E expression){ import std.exception; import core.exception : RangeError; try expression(); catch(RangeError t) return true; catch(Error t) return true; return false; } unittest(){ int[]x; assert(isThrown(x[1])); } ----
Mar 22 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Mar 22 2013
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Mar 22 2013