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.
