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
