What features of D are you using now which you thought you'd never goint to use?

[Jonathan M Davis]

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

- Jonathan M Davis