Transience of .front in input vs. forward ranges

[Andrei Alexandrescu]

On 11/4/12 11:40 AM, deadalnix wrote:
> 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.

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.

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.


Andrei