Le 04/11/2012 16:16, Andrei Alexandrescu a écrit :
On 11/4/12 9:36 AM, deadalnix wrote:
Let's put back relevant elements of the solution I propose :
1/ range preserve .front by default .
2/ Ranges that would get performance boost from invalidating .front can
propose a property (we called it .fast in the thread) that return a new
range that invalidate .front .
IMHO this property is deducible from the others:
fast!R == isInputRange!R && !isForwardRange!R &&
hasMutableIndirections!(ElementType!R)
I think it would be vastly better to avoid defining a new property of
ranges (that subsequently would need to be cross-checked by many
algorithms).
You can stop here. This shows that you didn't understood the proposal.
The whole point of the proposal is to avoid the cross checking part. See
code sample posted earlier in the discussion for full understanding.
Then we have additional scalability issues because all
derived ranges would need to propagate .fast etc. Then we need to cater
for odd cases such as random-access ranges being .fast.
The beauty of the proposal is that nothing NEED to be .fast .
The simpler way would be to simply state that input ranges can't
guarantee the persistence of .front after calling .popFront. This is
quite expected for input ranges, and no different for any object that
gives a char[]-based API; subsequently changing the object may change
the contents of the char[] returned.
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). This approach puts the burden in the right place - on the
implementers of specific algorithms supporting one-pass streaming.
