Transience of .front in input vs. forward ranges

deadalnix deadalnix at gmail.com
Sun Nov 4 09:26:32 PST 2012


Le 04/11/2012 17:57, Andrei Alexandrescu a écrit :
> Indeed I'd misunderstood. So I went back and my current understanding is
> that it's all about defining this:
>
> auto transient(R r) if (isInputRange!R)
> {
> return r;
> }
>
> Then certain ranges would implement a property .transient if there's an
> opportunity for e.g. reusing buffers (a la ByLine and ByChunk). At the
> end of the day, simply invoking r.transient for any range r would either
> get the optimized range or would vacuously return that same range.
>

Now we are on the same page. (and I like transient much better than .fast).

> As far as I can tell from the subsequent discussion, there are quite a
> few issues related to propagating transient by ranges that compose on
> top of other ranges. By and large, adding an optional attribute of
> ranges is difficult to make free or minimal in cost.
>

To sum it up, a transformation range should implement .transient if it 
can handle the fact that its source can be transient. The good news is 
that if it doesn't, then the program is still 100% correct. It is just 
slower.

So this approach promote program correctness, but still allow crazy 
bearded programmer to optimize the code where needed.

I think it fit nicely D's phylosophy, in the sense it does provide a 
safe, easy to use interface while providing a backdoor when this isn't 
enough.


More information about the Digitalmars-d mailing list