front stability

[Jesse Phillips via Digitalmars-d]

On Thursday, 2 June 2016 at 12:51:18 UTC, Steven Schveighoffer 
wrote:
> The counter-argument seems to be that if you cache the front 
> element, then then making a copy of the range via take can 
> repeat the cached element[4]. I find this argument severely 
> lacking -- non-forward ranges are not meant to be copied and 
> expected to operate properly, it's why we require calling save.
>
> [4] 
> https://github.com/dlang/phobos/pull/2606#issuecomment-58740715

I think front returning the same value every time is the 
appropriate behavior for every range (I've had many times I wish 
this weren't true so I wouldn't have to implement caching).

Map is no different, yes the function could technically change 
each time front is called, but that is an issue in the user code 
and not the implementation of map (map should only accept pure 
functions :))

I think the example of take() is a valid criticism. It is the 
issue of value ranges vs reference ranges all over again. Due to 
these distinct range types, providing a range to a function 
invalidates that range within the scope. It is not possible to 
know if the range will start at the same spot prior to calling 
function or if it will start after. In the case generator, we see 
a hybrid which isn't the only range that will do front() caching.

Practically we don't run into issues with undefined behavior in 
our code, probably because we don't change out the type of range 
being used very often. I don't have a solution for this problem, 
but think having generator() add a new uncertainty (does calling 
front() a second time advance my range?) is a very bad precedence 
to set in Phobos.