std.v2020.algorithm etc[ WAS: Is run.d going to be expand for runtime and the phobos library?]

[Paul Backus]

On Wednesday, 24 June 2020 at 20:05:27 UTC, Stanislav Blinov 
wrote:
> On Wednesday, 24 June 2020 at 16:25:31 UTC, Adam D. Ruppe wrote:
>> I'm barely reading this thread, but could @live be useful with 
>> input ranges too?
>
> I don't think it can be, at least in its current form, but my 
> reasoning behind making them non-copyable is pretty much the 
> same as one behind @live and pointers: at any given moment, 
> there can be only one owner of an input range's iteration state.
> For some reason, Andrei equates that to not being able to read 
> from the same source. ¯\_(ツ)_/¯

I think the missing piece here is that it's entirely possible for 
an input range to "borrow" its iteration state from somewhere 
else, rather than owning it. For example, a pointer to an input 
range is, itself, considered an input range, because of how the 
`.` operator does automatic dereferencing:

struct Example
{
     int i;

     bool empty() { return false; }
     int front() { return i; }
     void popFront() { ++i; }
}

static assert(isInputRange!(Example*));

Clearly there is no need for `Example*` to be non-copyable, even 
if we think `Example` ought to be.