foreach() behavior on ranges

[Steven Schveighoffer]

On 8/25/21 7:26 AM, Alexandru Ermicioi wrote:
> On Wednesday, 25 August 2021 at 11:04:35 UTC, Steven Schveighoffer wrote:
>> It never has called `save`. It makes a copy, which is almost always 
>> the equivalent `save` implementation.
>>
> 
> Really?
> 
> Then what is the use for .save method then?
> The only reason I can find is that you can't declare constructors in 
> interfaces hence the use of the .save method instead of copy constructor 
> for defining forward ranges.

The `save` function was used to provide a way for code like 
`isForwardRange` to have a definitive symbol to search for. It's also 
opt-in, whereas if we used copying, it would be opt-out.

Why a function, and not just some enum? Because it should be something 
that has to be used, not just a "documenting" attribute if I recall 
correctly.

Keep in mind, UDAs were not a thing yet, and compile-time introspection 
was not as robust as it is now. I'm not even sure you could disable copying.

> 
> We have now two ways of doing the same thing, which can cause confusion. 
> Best would be then for ranges to hide copy constructor under private 
> modifier (or disable altoghether), and force other range wrappers call 
> .save always, including foreach since by not doing so we introduce 
> difference in behavior between ref and value forward ranges (for foreach 
> use).

There would be a huge hole in this plan -- arrays. Arrays are the most 
common range anywhere, and if a forward range must not be copyable any 
way but using `save`, it would mean arrays are not forward ranges.

Not to mention that foreach on an array is a language construct, and 
does not involve the range interface.

-Steve