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