front stability

[default0 via Digitalmars-d]

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 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

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