Transience of .front in input vs. forward ranges

[Andrei Alexandrescu]

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.

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

> I've looked over std.algorithm --
> there are a *lot* of places with this assumption. Instead of getting
> correct default behaviour, you get a whole bunch of broken code with
> buggy behaviour, unless you first rewrite a lot of code in
> std.algorithm (and probably std.range as well).

Could you please put together a list of these algorithms so we have it? 
Thanks.

> Furthermore, afterwards there is still no safety net: accidentally
> create a transient forward range?

But that goes for any incorrect range.

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


Andrei