On Thursday, 30 June 2016 at 18:07:41 UTC, Steven Schveighoffer
wrote:
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
<digitalmars-d@puremagic.com
<mailto:digitalmars-d@puremagic.com>>:
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 <digitalmars-d@puremagic.com
<mailto:digitalmars-d@puremagic.com>>:
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
Can we have ranges that disallow using them like rangeCache =
range; without sacrificing usability in other cases? Going
forward having ranges that simply do not compile when used that
way would probably make lots of people actually honor .save and
allow the compiler to point out buggy code (even if, in the end,
.save really comes down to a no-op for many ranges).
