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.
