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
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 *eve
On Thu, 21 Mar 2013 13:29:35 -0400
"Jonathan M Davis" 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
On Thu, 21 Mar 2013 13:48:54 -0400
Nick Sabalausky 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/
21-Mar-2013 21:48, Nick Sabalausky пишет:
On Thu, 21 Mar 2013 13:29:35 -0400
"Jonathan M Davis" 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 au
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" 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 th
On Thursday, March 21, 2013 13:52:12 Nick Sabalausky wrote:
> On Thu, 21 Mar 2013 13:48:54 -0400
>
> Nick Sabalausky 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
On Thursday, March 21, 2013 13:48:54 Nick Sabalausky wrote:
> On Thu, 21 Mar 2013 13:29:35 -0400
>
> "Jonathan M Davis" 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'
On Thu, 21 Mar 2013 11:04:31 -0700
"H. S. Teoh" 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 c
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 thro
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 t
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
> >
>> - 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 b
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);
On Thu, 21 Mar 2013 20:24:40 +0100
Philippe Sigaud 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 t
On Thu, 21 Mar 2013 21:41:52 +0100
"jerro" 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 fo
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
On Thu, 21 Mar 2013 21:55:10 -0400
"Jonathan M Davis" 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.
>
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(
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
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,
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 th
On Thursday, March 21, 2013 22:03:25 Nick Sabalausky wrote:
> On Thu, 21 Mar 2013 21:55:10 -0400
>
> "Jonathan M Davis" 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 e
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.
24 matches
Mail list logo
