Transience of .front in input vs. forward ranges

[deadalnix]

Le 05/11/2012 22:51, Andrei Alexandrescu a écrit :
> On 11/5/12 9:45 PM, H. S. Teoh wrote:
>> Besides, almost *all* of those wrapper ranges are currently _broken_ for
>> transient ranges. You get undefined behaviour when you inadvertently
>> pass a transient range to them.
>
> It's not undefined behavior, it's just surprising behavior. UB would be
> a fair amount more worrisome.
>

Unless you know the internal implementation of the range, it is 
undefined (nothing in the spec specify what the range does in this case, 
which IS undefined behavior).

>> With Andrei's proposal, all code that assumes transient .front with
>> input ranges are broken by definition.
>
> I think this should be: all code that DOES NOT assume transient .front
> with input ranges is broken.
>

You never addressed the std.array.array() problem. Neither the fact that 
forward ranges may require to be transient (I have that in my rubik's 
cube solver, and H. S. Teoh seems to needs that too).

>> How is this any better than deadalnix's solution? From what I can tell,
>> it's a lot worse, for all of the above reasons.
>
> I think we should start from here: the .transient proposal will not be
> accepted because it is too complex. Consider it a baseline that other
> proposals would be evaluated against. Then let's see how to devise a
> robust, simple solution.
>

I'd like to see a proposal discarded in favor of a better proposal. I'm 
certain I can say that we don't have one. Let me explain what is wrong 
in your proposal (=> forward range = non transient / input range = 
transient).

First two concepts are packed into one. I can safely say that both are 
not related, and uses cases has already been presented in all possible 
combination of input/forward transient or not. This usually seems like a 
win, but ends up creating a more complex situation at the ends. I've 
made that mistake quite a lot of time myself, surely enough to be sure 
that this is a bad idea.

See for instance how the private method made final automagicaly (which 
sounds nice at first) create inconsistent behavior when it come to NVI 
as explained in TDPL. This is typical of how different concept packed 
into one tends to explode at some point.

Additionally, the proposed solution put a responsibility on the 
developer : he/she must ensure that all its code with input ranges is 
compatible with transient range.

The fact is that transient stuff are highly unusual in most programming 
languages (even when possible, it is usually avoided like plague), and 
that all input ranges will not be transient. This WILL result in a lot 
of code in the field using input range but not supporting when it is 
transient.

Putting the responsibility on the programmer never worked since 
programmer exists, and it is not going to improve soon.