popFrontExactly?

[Jonathan M Davis]

On Friday, November 23, 2012 17:01:04 monarch_dodra wrote:
> You could ask the question the other way around: Why would you
> pop a certain amount of elements, if you don't even know your
> range actually *holds* that many elements? Why do you even need
> the safeguard in the first place?

It would be easy to have a file or message format where the value of one 
sequence of bytes tells you how many are left or how many are in the next 
section. If you were going to pop those bytes without looking at them, then 
such a check would be necessary if you don't actually know how many bytes are 
left in the range (e.g. you're dealing with a simple, input range).

That being said, I've never written code which used popFrontN when I didn't 
know how many elements were going to be popped off. If I use popFrontN, either 
I know the range's length, or I know that it has at least as many elements as 
I'm trying to pop off (because I used take on it or otherwise iterated over a 
part of the range). If I don't know how many elements there are to pop off, 
then I'm going to be popping them off one by one and checking empty - though if 
I relaly don't need to actually look at each element, it would arguably be 
better to just use popFrontN. In most cases though, if I don't know the number 
of elements left, then I'm probably looking at them.

In any case, there _are_ cases where you could legitimately call popFrontN 
without knowing if there are at least n elements to pop off, but I never use it 
that way.

> Still regardless of performance, the (my) motivating factor is
> that when you use "drop", it pretty much silently fails if your
> range doesn't have the amount of elements. IMO, in the long run,
> this makes "drop" *un*-safe...

I don't know if we can get away with it or not (given the possibility of 
breaking code), but given that drop doesn't return how many elements were 
popped (unlike popFrontN), I'd favor simply making it drop the exact number of 
elements. Then if you wanted popFrontExactly, you could just do

range = drop(range, n);

It's slightly less efficient (assuming that the optimizer doesn't help you out), 
but it avoids having to create a new function.

It was already one of Andrei's complaints about drop when it was introduced 
that there was no way to determine how many elements were actually dropped, so 
he might favor the idea of making drop assert that it drops the correct number 
of elements rather than using popFrontN. The one concern would be whether 
making that change would break any code. Given that you can't know how many 
elements were actually dropped and the fact that I suspect most of us don't 
call popFrontN unless we know that there were at least that many elements to 
drop, the amount of code broken might be negligle if not outright 0. But we 
don't want to break code, so that may just not be an option.

Still, if we can't do that, and we're trying to minimize the number of stray 
functions in std.range, then we could just create drop(Front)Exactly and 
dropBackExactly and let people do

range = dropExactly(range, 5);

if they want popFrontExactly.

- Jonathan M Davis