Transience of .front in input vs. forward ranges

[Era Scarecrow]

On Saturday, 3 November 2012 at 23:19:11 UTC, H. S. Teoh wrote:
> I wish Andrei would give some input as to how we should proceed 
> with this. I do consider this a major issue with ranges, 
> because for efficiency reasons I often write ranges that have 
> transient .front values, and they can lead to subtle bugs with 
> the current implementation of std.algorithm. It would be good 
> to settle on this issue one way or another. I'd be happy even 
> if the decision is to say that transient ranges are invalid and 
> shouldn't be considered "real" ranges. Anything is better than 
> the current nebulous state of things which only leads to subtle 
> bugs for the unwary.

  From watching and gleaming from what I have so far, I can only 
think that transient should NOT be the default way that ranges 
work (as it causes too many problems); However transient should 
be allowed (and available) when possible.

  I can only think that perhaps using a template to determine if 
it's transient should be present, that way it's a simple flag to 
enable/disable and should propagate anywhere that that range was 
used.

struct Range(bool isTransient=false) {
   static if (isTransient) {
     //front and transient
   } else {
     //front and non-transient
   }
}

  Unless someone thinks this is a bad approach?