Transience of .front in input vs. forward ranges

[Andrei Alexandrescu]

On 11/4/12 11:36 AM, Dmitry Olshansky wrote:
>
> The fact that algorithm doesn't save iteration state != it counts on
> transient .front.

I didn't claim that. My strongest claim was: 
input-range-having-front-with-mutable-indirection IMPLIES 
no-transience-guarantee.

Note the IMPLIES (not EQUIVALENT) and no guarantee as opposed to 
guaranteed change of contents.

> A simple example of std.array.array will do - it iterates range once and
> pumps elements into appender/builder "sink". So it doesn't require
> forward range but just that elements are not _aliased_ under the hood.

No surprise here.

> Another example is dirEntries - it returns entries with immutable
> strings, but it can't save iteration state. It does work with array
> because of no aliasing of .front values.

This example is actually nice because it shows that indeed an input 
range with NO mutable indirection on ElementType guarantees non-transience.


Andrei