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;").
