On 06/25/2013 09:21 PM, Jonathan M Davis wrote:
On Tuesday, June 25, 2013 19:33:32 Timon Gehr wrote:
On 06/25/2013 07:16 PM, Andrei Alexandrescu wrote:
On 6/25/13 4:47 AM, Timon Gehr wrote:
Good point, but takeExactly currently is not a better choice due to its
poor quality of implementation.
https://github.com/D-Programming-Language/phobos/blob/master/std/range.d#
L2904>
What's wrong with it?
Andrei
It either has all the overhead of take or does not properly propagate
the underlying range's capabilities.
I don't think you're taking into account what take does.
I think I do.
The primary case when
takeExactly doesn't use take is when the range doesn't define length, in which
case, the best that you can get out of it is a forward range, and that's
exactly what it does.
On the other hand, when take is used, it _does_ propagate the original range's
capabilites appropriately. take was specifically engineered to avoid wrapping
ranges when it doesn't need to, so it shouldn't result in any any extra
overhead if it isn't necessary.
Take will check the wrapped range's 'empty' repeatedly. takeExactly does
not need to do that at all.
(overhead)
In particular, if the range has slicing, then
Take is aliased away to the original type, and a slice is returned. The one
case that I can think of where you really lose out on a range's capabilties
with take is with bidirectional ranges which don't have slicing as they end up
as forward ranges rather than bidirectional ranges, but without slicing, you
can't do better than that.
I'm fine with that.
I suppose that takeExactly's Result type (in the case where it actually
creates its own type) could (and should) forward the primitives associated
with hasMobileElements and hasAssignableElements (which it currently doesn't),
but that's all I can see that's missing.
...
(not properly propagating the underlying range's capabilities.)
