front stability

[Steven Schveighoffer via Digitalmars-d]

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 at puremagic.com <mailto:digitalmars-d at 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 at puremagic.com
> <mailto:digitalmars-d at 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