More tricky range semantics

[Tobias Pankrath via Digitalmars-d]

On Friday, 16 January 2015 at 18:12:03 UTC, Joseph Rushton 
Wakeling wrote:
> On Friday, 16 January 2015 at 17:22:42 UTC, Tobias Pankrath 
> wrote:
>> Ah, now I understand you. Since copy-construction is undefined 
>> for ForwardRanges, you cannot guarantee this. Things would be 
>> better, if we had required that this(this) does the same as 
>> .save or must be @disabled.
>
> I'm not sure I follow what you mean by this ... ?

If you pass a forward range of type T (something that passes 
isForwardRange!T) to a function you have no guarantees on what 
will happen. It could be:

     • compilation failure
     • reference semantics (changes are reflected outside the 
function
     • value semantics (no change are reflected outside the 
function)

The implementer of the range can choose one. Although I tried it 
now, and @disable this(this) does prevent isForwardRange!T to 
pass. I don't know if that changed recently or is just out of 
line with the documentation/specification.