called copy constructor in foreach with ref on Range

[Stanislav Blinov]

On Tuesday, 23 June 2020 at 05:24:37 UTC, H. S. Teoh wrote:
> On Tue, Jun 23, 2020 at 03:25:55AM +0000, Stanislav Blinov via 
> Digitalmars-d-learn wrote:
>> On Tuesday, 23 June 2020 at 02:41:55 UTC, Jonathan M Davis 
>> wrote:
>> > We'd need some major redesigning to make uncopyable ranges 
>> > work, and personally, I don't think that it's worth the 
>> > trouble.
>> 
>> Of course we would. Andrei is entertaining changing the whole 
>> input range API. Though he, like you, seems opposed to the 
>> idea of uncopyables.
> [...]
>
> 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. Like Jonathan said before - after you copied, you 
should only use the copy and not the original. Input range is a 
one-off iterable. You either consume it yourself, or give it away 
to someone else to consume. You can't do anything useful with it 
besides consuming it. But you can't give it away if it's copyable 
- you'd be giving someone a reference to mutable state which you 
also keep. Which brings about those very problems already talked 
about in this thread.  So if you "only should use the copy", well 
then duh, let's make it official and force you to write a move 
then (turning attempts to copy into compile errors)! Assuming, of 
course, that we do establish that .init must be an empty range. 
You'd be left with a valid state, callee would be given a valid 
state, neither of you would stomp on each other.

ByLine, just to become copyable, is made refcounted. It allocates 
its guts on the heap and molests an integer, all because it wants 
to remain copyable. But it is a call to "move" that is 
complication?

Or, perhaps, a complication would be partial consumption? E.g. 
chaining a take + map combo, but still wanting to consume 
remainder. That is solved by making wrapping ranges propagate the 
`source`, naturally, by moving it. Pretty straightforward.