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