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

Timon Gehr timon.gehr at gmx.ch
Tue Jun 25 12:42:17 PDT 2013


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



More information about the Digitalmars-d mailing list