On 6/30/16 11:56 AM, Mathias Lang via Digitalmars-d wrote:
2016-06-02 14:51 GMT+02:00 Steven Schveighoffer via Digitalmars-d <[email protected] <mailto:[email protected]>>:I have always treated ranges with this expectation: I think the case is pretty clear here, and I'm in agreement with you. I just want to add a note on the following point: 2016-06-02 14:51 GMT+02:00 Steven Schveighoffer via Digitalmars-d <[email protected] <mailto:[email protected]>>: 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. The compiler is blatantly guilty of doing so: https://issues.dlang.org/show_bug.cgi?id=15413
I don't think that's a bug. The range definition says nothing about what happens on copying, or that non-forward ranges shouldn't be copied. What it says is that if you make a copy and use both, then there is no guarantee what happens. This is the use case in the argument I referenced.
Unfortunately, for the likes of forward ranges, copying mainly always does the same thing as .save does. So you have tons and tons of code that doesn't properly use .save. Such is the way things are, and I'm not sure it will ever get better :(
-Steve
