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
