called copy constructor in foreach with ref on Range

[Steven Schveighoffer]

On 6/23/20 9:47 AM, Sebastiaan Koppe wrote:
> On Tuesday, 23 June 2020 at 07:30:29 UTC, Stanislav Blinov wrote:
>> On Tuesday, 23 June 2020 at 05:24:37 UTC, H. S. Teoh wrote:
>>> I'm also wondering what's the motivation behind supporting 
>>> non-copyable ranges, and whether it's worth the effort and inevitable 
>>> complications to support it if it's a rare use-case.
>>>  Do you have any compelling use-case in mind, that might make this 
>>> worthwhile?
>>
>> This compelling use case is staring at us from comments in this very 
>> thread.
> 
> I am a bit on the fence about having input ranges be non-copyable. 
> Initially I liked the idea very much; I am a big fan of 'unique' semantics.
> 
> But just because most people don't expect hot/destructive reads, doesn't 
> mean we should impose such a hard restriction on input ranges. There are 
> use cases for popping from an input range from different places. An 
> obvious one would be parsing data from the network, where you pass the 
> input range into helper functions that parse sub-sections of the data.

You can pass a reference if you need to, there's nothing wrong with that.

> They can be made to work for sure, but it doesn't make it cleaner.
> 
> On the other hand, most of the time, non-copyable is exactly what you 
> need...

Most of the time algorithms return rvalue ranges anyway, so move is not 
necessary. I think it would actually affect calls very little, and where 
it does affect them, you may find it actually fixes issues that you 
aren't aware of.

-Steve