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.
