Transience of .front in input vs. forward ranges

[deadalnix]

Le 06/11/2012 01:21, Andrei Alexandrescu a écrit :
>> 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?
>

I certainly don't ! I'd be happy to switch to another solution granted 
it is superior. I just don't see any right now, which obviously don't 
mean none exist.

>> 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.
>

To be honest, my biggest fear isn't that this proposal is rejected, but 
that we fallback as default on the input range = transient / forward 
range = non transient scheme, because we fail to come up with something 
better, or that the status quo is choosen (as both seems to me worse 
than the .transient proposal).

Now, as previously said, if someone come up with something better, I'd 
be happy to drop it completely. I'm not pushing this proposal because it 
is mine.