Transience of .front in input vs. forward ranges

[Dmitry Olshansky]

11/4/2012 9:02 PM, 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.

Indeed, but it wasn't your claim that I meant. It's fine with me but 
it's hardly moving us forward.

I was investigating your simplified proposal and its consequences for 
e.g. std.array.array. And apparently forgot to make the central point.

I was mostly going by:

 > The simpler way would be to simply state that input ranges can't 
guarantee the persistence of .front after calling .popFront.

and

 >The algorithms that need to worry about .front's transience are only 
the ones that work with input ranges (as opposed to forward ranges or 
stronger).

And conclude that applying this simple rule to std.array.array* means it 
has to assume non-transient elements and somehow copy/dup'em. Problem is 
we don't have generic function to make 100% guaranteed unaliased copy 
(it could omit doing any work on non-aliased objects).

Also that it misses forward ranges that have aliased .front, assuming 
they are non-transient.


*It has to work with input ranges as I noted below.

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


-- 
Dmitry Olshansky