popFrontExactly?

[Jonathan M Davis]

On Friday, November 23, 2012 03:55:21 Kapps wrote:
> Is it really that big an issue to have a few more methods than
> standard ranges would need? Before it certainly would be annoying
> to have to check if the range supported it, use that, and if not
> fake it, but now we have UFCS. It would be simple to have a basic
> fallback implementation of methods such as popFrontExactly, then
> simply use range.popFrontExactly to get the more performant one
> if the range supports it, and if not get the fallback.
> 
> It would have to be clear in the documentation that these are
> optional methods however, and are recommended only if performance
> is required (and if the range supports it in a way that isn't
> simply an alternate implementation of the fallback).

You misunderstood. popFrontExactly/popFrontNExactly wouldn't be on any ranges 
any more than popFrontN or drop are on any ranges. They're free functions in 
std.range which either slice a range or call its popFront in a loop (depending 
on the type of range) in order to pop the appropriate number of elements off, 
and popFrontNExactly would be the same.

It may very well be that we should add popFrontNExactly in order to get that 
extra efficiency gain over popFrontN in the cases where you know that the range 
contains at least the number of elements being popped. It's just that it's 
getting a bit ridiculous how many of these sorts of methods we have. If you 
add popFrontNExactly, you need popBackNExactly and probably drop(Front)Exactly 
and dropBackExactly as well. Any time that another function like this gets 
suggested, you end up having to add a number of similar functions, and it adds 
up. Its arguably a bit ridiculous to have so many functions that do almost the 
same thing but not quite.

I think that we'll probably need to add them in this case due to efficiency 
concerns, but it's not without cost. We don't want too many stray functions 
doing almost the same thing in Phobos.

- Jonathan M Davis