Is this a bug in iota?

[Jonathan M Davis]

On Thursday, April 19, 2012 10:14:39 Somedude wrote:
> Le 19/04/2012 10:07, Jonathan M Davis a écrit :
> > Having an assertion may be desirable, but the bug is in the usage of iota,
> > not iota itself. At best, the assertion would help indicate that the
> > caller has a bug. It's exactly the same as doing something like
> > 
> > for(size_t i = 3; cond; --i) {}
> > 
> > It's basic integer arithmetic. If you subtract from the minimum value that
> > the integral type will hold, then its value will wrap around to the
> > maximum. So, while adding an assertion would be desirable, I don't see
> > how this could be considered a bug in iota.
> > 
> > - Jonathan M Davis
> 
> I don't get it, for me iota has nothing to do with the problem, the
> problem is in the implementation of popfront(), which should check
> beforehand whether the range is empty, right ?

Maybe, maybe not. popFront _must_ succeed. It has three options if the range 
is empty: assert, throw an exception, or just assume that it's going to 
succeed and choke in whatever manner the implementation ends up choking if the 
range is empty when it tries to pop an element from an empty range.

Very few ranges are going to throw exceptions from popFront, because that 
incures overhead, and really, it's a bug in the caller if they keep trying to 
pop elements from an empty range. So, throwing an exception really isn't the 
correct behavior.

Asserting is an option, and since iota is templated, it should probably do 
that (asserting in non-templated code is more debatable, because it'll only be 
there if Phobos itself is compiled without -release rather than the program or 
library call it - in most cases, such an assertion would probably never end up 
being run, because using a release version of Phobos is the default). But it's 
not doing that right now. An enhancement request for such would be 
appropriate.

Currently, it's taking the third option of not checking, and so you get this 
problem. But the fact that the code is attempting to pop off an element from an 
empty range is a bug in the caller, not popFront.

- Jonathan M Davis