front stability

[Jonathan M Davis via Digitalmars-d]

On Thursday, June 02, 2016 08:51:18 Steven Schveighoffer via Digitalmars-d 
wrote:
> I'd say violating the expectations of what popFront and front do is more
> egregious than a particular use case, no matter how valid that case is.
> I'd like to fix this bug, but I see there were quite a few major D
> contributors in the camp that wanted this function to behave the way it
> is. So I'd rather first debate the merits here.

I am in violent agreement with you on this. Copying ranges is unspecified
behavior. If you want an actual copy, you have to call save. front must
return the same element on every call until popFront is called, and while in
some cases, that means returning an element that is equal every time rather
than being an identical value (e.g. range.map!(a => to!string(a))()), it's
not okay for front to return a different element without popFront being
called. I think that for a range to do otherwise is a _very_ clear violation
of the range API.

If you have to do stuff like caching the value of front in order to keep it
consistent, then you're stuck doing that, otherwise it's not a valid range.
I really don't see how there's much of an argument otherwise.

- Jonathan M Davis