popFrontExactly?

[monarch_dodra]

On Friday, 23 November 2012 at 15:48:04 UTC, Dmitry Olshansky 
wrote:
> 11/23/2012 9:19 AM, 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.
>
> This gets interesting - how did you know it? The number of 
> elements to pop I mean.

Usually, either by a previous iteration, or just because it is 
statically know the range will have that many elements. Or that 
it *should* have that many elements.

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?

> I'd say the cases where hasLength is true and there is no 
> slicing is quite rare. It'd be interesting to know what are 
> these cases that it this set of helpers tries to speed up. I 
> mean a list of:
> -algorithms where popFrontN is used
> -ranges that allow hasLength but not slicing and work with the 
> said algorithm

What about the case of plain bidirectional ranges? That's the one 
that's being sped up.

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...