Transience of .front in input vs. forward ranges

[deadalnix]

Le 06/11/2012 02:40, Andrei Alexandrescu a écrit :
> On 11/6/12 2:44 AM, deadalnix wrote:
>> 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).
>
> I think the simplification of input range = transient and forward range
> = not transient has a lot going for it. It is simple, easy to explain
> and understand, and builds on simple real-life examples (buffered input
> and singly-linked lists). Clearly adding a new notion to the soup makes
> for more expressiveness, but it also makes for more complexity and
> subtlety in support for niche ranges. This should not be neglected.
>

At this point, if transient is out I'd prefer Jonathan's proposal were 
everything is non transient. This is clearly simpler to use and break 
less code.

Indeed, the added complexity of .transient exists. The beauty of it is 
that it is possible to write 100% correct code without even knowing 
.transient exists. This is why I like this option : the added complexity 
only exists for the programmer that what to explore the arcane of the 
language (which include you and me, but not most D users).