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

Jonathan M Davis jmdavisProg at gmx.com
Tue Jun 25 13:37:06 PDT 2013


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


More information about the Digitalmars-d mailing list