Transience of .front in input vs. forward ranges

[Jonathan M Davis]

On Tuesday, October 30, 2012 15:29:17 H. S. Teoh wrote:
> The problem, of course, is how to check of a range has transient .front
> or not. I proposed adding a .isTransient member to the range, but this
> depends on the range implementor to remember to mark the range with
> .isTransient=true, and we know that coding by convention is not
> scalable. So here's another idea:
> 
> template isTransient(R) if (isInputRange!R)
> {
> static if (is(typeof(R.front) : immutable(typeof(R.front))))
> enum isTransient = false;
> else
> enum isTransient = true;
> }
> 
> The idea is that value types are implicitly convertible to immutable,
> and value types are non-transient. Reference types, if they can be made
> immutable, ensures that calling popFront() will never invalidate them
> (by definition of immutable).

This won't work at all. All that's required is for you to have a range of 
class objects (e.g Object[]), and suddenly it would be claiming that the range 
was transient even though it isn't. Whether the return type is immutable 
really doesn't have anything to do with whether or not the result of front 
will be valid after popFront is called - or at least the lack of immutable 
doesn't say anything about it.

I still posit that this sort of range is extremely rare and abnormal, so if we 
do anything to support them, I think that it's perfectly fair that they have 
to do something to mark themselves as transient rather than trying to 
determine it externally - especially because I don't think that it's really 
possible to determine it externally.

- Jonathan M davis