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. 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
And I agree with Jonathan that adding a bunch of helpers should be
justified. Any helper function like say 'enforce' has utility only as
long as simplifies a usage of a _frequent_ enough pattern.
If it simplifies/speed up certain algorithms there is no guilt in just
using them internally.
--
Dmitry Olshansky
