Transience of .front in input vs. forward ranges

[H. S. Teoh]

On Tue, Nov 06, 2012 at 01:44:28AM +0100, deadalnix wrote:
> Le 06/11/2012 01:21, Andrei Alexandrescu a écrit :
[...]
> >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'd like to hear a counterproposal to the .transient idea. Let's not get
into a battle of words with nothing on the table to discuss.


[...]
> 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).
[...]

Yeah, that is my fear also. Which is why I'm making noise about this
issue.

The status quo is definitely out of the question, as it leads to
undefined/unspecified behaviour with basically no warning.

Conflating transience with input range is not workable IMO, because it
leads to leaky abstractions like transient forward ranges being
considered non-forward ranges because we arbitrarily decided that
forward ranges cannot be transient. I've already given a number of
non-trivial examples of transient forward ranges, and apparently
deadalnix has also encountered the same issue. Denying these cases just
for the sake of holding on to an idealized abstraction is only further
proof that the abstraction is leaky. We all know from experience that
leaky abstractions will only lead to trouble down the road.

The only other remaining proposal so far is Jonathan's, that is to
redefine all ranges to be non-transient. Then we fix byLine() to be
non-transient, and everything else will work with no further trouble.
We also don't get to use std.algorithm with any transient ranges, and
will in all likelihood reinvent std.algorithm everywhere a transient
range pops up. I don't see this as a viable solution either.

So the .transient idea currently seems to be the best we have. I'd love
to hear a superior proposal, if there is one.


T

-- 
I don't trust computers, I've spent too long programming to think that
they can get anything right. -- James Miller