On Tuesday, June 25, 2013 21:42:17 Timon Gehr wrote: > 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.
It only does that with assertions. takeExactly could do exactly the same, or the assertion in Take could be removed. The overhead is gone with -release regardless. The only overhead that's required is the decrementing of the length, and that's required by Take's semantics. takeExactly avoids that because it's able to assume that the underlying range is large enough. Regardless, the overhead for take is minor, but it _is_ better to use takeExactly when you can. > > 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.) With regards to a couple of attributes that aren't even used much. Yes, they should be propagated, but you seemed to be saying that there were big problems with takeExactly, whereas the only issue is very minor, and it would be very quick to fix it. - Jonathan M Davis