front stability

[ag0aep6g via Digitalmars-d]

On 06/02/2016 02:51 PM, Steven Schveighoffer wrote:
> For example, generate.popFrontN does nothing. generate.drop does
> nothing. And of course, calling front multiple times does not yield the
> same answer, unless you provide a lambda that does the same thing every
> time (a useless case).

That's just broken.

> 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.

Completely agree with you here. You can only use one of the copies. When 
you call popFront on one of them, that invalidates the other one. To get 
two valid copies, use .save.

generate should not try to go beyond the contract here when it means 
broken behavior elsewhere.