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
