Transience of .front in input vs. forward ranges

[Andrei Alexandrescu]

On 11/6/12 1:26 AM, deadalnix wrote:
> 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).

That would be unspecified 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.

Good solutions are found in the minds of people. Starting from the idea 
that .transient is unacceptably complicated, work from that angle. You 
can't claim you have reached perfection in design can you?

> Let me explain what is wrong
> in your proposal (=> forward range = non transient / input range =
> transient).

I am well aware of the relative tradeoffs. Arguing for .transient is 
futile at this point. What we need to do is find something better.


Andrei