Transience of .front in input vs. forward ranges

[Tommi]

On Monday, 12 November 2012 at 20:52:07 UTC, Jonathan M Davis 
wrote:
> That wouldn't work. It's the complete opposite of what a 
> generative range would require if it generates the return value 
> in front. Narrow strings in particularly would be screwed by 
> it, because their front is calculated, and
> since it's a free function, as is popFront, there's no way
> to save the return value of front in popFront. It has to
> be calculated in front, and it's not at all transient.
>
> It also screws with the ability to have sealed containers, 
> since in that case, something like front would never
> return by ref.
>
> The refness of front's type really shouldn't have anything
> to do with its transience. They're completely unrelated.

I didn't understand any of those arguments, so perhaps I still 
don't fully comprehend this issue.

Persistence
-----------
I thought persistent X means that there's a dedicated storage 
space for X where it will exist after front returns and X's value 
will not be tampered with by calling popFront. That notion of 
persistence led to me into thinking that persistent front could 
(and really should) return either a reference to X or a const 
reference if the range doesn't want to allow mutation through 
front.

Transience
----------
The other side of the coin in my thinking was that transient 
means that X doesn't have a dedicated storage space. So transient 
X could be a variable that's local to function front, or it could 
be that X is stored in a buffer and will exist there after front 
returns, but the buffer would be overwritten by a call to 
popFront. And that notion of transience led me into thinking that 
transient front could never return a reference.

NOTE: All of the above assumes that D were designed so that all 
types had value semantics.