foreach() behavior on ranges

[Joseph Rushton Wakeling]

On Wednesday, 25 August 2021 at 10:59:44 UTC, Steven 
Schveighoffer wrote:
> structs still provide a mechanism (postblit/copy ctor) to 
> properly save a forward range when copying, even if the guts 
> need copying (unlike classes). In general, I think it was a 
> mistake to use `.save` as the mechanism, as generally `.save` 
> is equivalent to copying, so nobody does it, and code works 
> fine for most ranges.

Consider a struct whose internal fields are just a pointer to its 
"true" internal state.  Does one have any right to assume that 
the postblit/copy ctor would necessarily deep-copy that?

If that struct implements a forward range, though, and that 
pointed-to state is mutated by iteration of the range, then it 
would be reasonable to assume that the `save` method MUST 
deep-copy it, because otherwise the forward-range property would 
not be respected.

With that in mind, I am not sure it's reasonable to assume that 
just because a struct implements a forward-range API, that 
copying the struct instance is necessarily the same as saving the 
range.

Indeed, IIRC quite a few Phobos library functions program 
defensively against that difference by taking a `.save` copy of 
their input before iterating over it.

> What should have happened is that input-only ranges should not 
> have been copyable, and copying should have been the save 
> mechanism. Then it becomes way way more obvious what is 
> happening. Yes, this means forgoing classes as ranges.

I think there's a benefit of a method whose definition is 
explicitly "If you call this, you will get a copy of the range 
which will replay exactly the same results when iterating over 
it".  Just because the meaning of "copy" can be ambiguous, 
whereas a promise about how iteration can be used is not.