range.save

[Sönke Ludwig via Digitalmars-d]

Am 19.11.2015 um 22:30 schrieb Freddy:
> Does anyone else think range.save is a hack? I often find myself
> forgetting to call range.save in my generic code with my unittests
> working fine. Also, working with a range of ranges may forget to call
> range.save.(Ex: [1,2,4].repeat)

I think that .save is a serious design flaw in the range API and there 
must me countless theoretical or future bugs lurking in todays code 
bases, only working by chance due to undefined algorithm behavior.

The problem is that all of the alternatives that were discussed all had 
different trade-offs and solving the .save issue would lead to other 
issues/limitations (or at least AFAIR there hasn't been a suggestion 
where that wouldn't be the case). And since we now already have an API, 
that wouldn't help anyway.

Maybe we could inject code into existing ranges that, in debug mode, at 
least causes assertions to trigger whenever an operation is done on an 
outdated copy of an input range (or of a non '.save'd forward range). 
That could then be advertised as a standard pattern for user defined 
ranges ("mixin RangeSemantics;").