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

[Stanislav Blinov]

On Saturday, 20 June 2020 at 20:09:56 UTC, Steven Schveighoffer 
wrote:
> On 6/20/20 3:16 PM, Stanislav Blinov wrote:
>> There should be a `move` at that return. There's no NRVO, the 
>> compiler makes a copy there.  Which, of course, it wouldn't be 
>> able to if R was non-copyable :)
>
> Yeah, it needs to use move. But the usage doesn't change, which 
> is what I thought you were referring to.

The usage does change. Because then (i.e. if input ranges were to 
be made non-copyable):

auto r = makeInputRange;
auto rem = r.find!pred;

...no longer compiles. And *that* will be all over Phobos, which 
is my original point about required massive changes. Which, as it 
turns out, may not be that bad of a thing in principle (though, 
of course, going over all parts of Phobos that touch ranges to 
fix them would be a huge endeavor).

>> It *may* become a move under Walter's proposal:
>> but until then?..
>
> You'd have to modify Phobos.

Exactly.

>>> There have been a few libraries released that use 
>>> non-copyable structs to model things that making copies of 
>>> will prove problematic. For instance, file handles. And 
>>> people seem to be able to use these reasonably well.
>> 
>> We're talking ranges here, not file handles :) Most algorithms 
>> in Phobos take ranges by value.

> Which means that you have to destroy the original, because it's 
> no longer valid.
>
> Today, you do:
>
> auto otherRange = inputRange.find(something);
>
> use(inputRange); // invalid, but compiler lets you. And it 
> probably messes up otherRange too.

Yeah, that's a good point, thanks.

>>> But the larger point is that true input-only ranges are rare. 
>>> The only problem is for classes, since you cannot invoke a 
>>> copy constructor on those.
>>>
>>> It would be a drastic change, I don't see it happening. But 
>>> the status quo of save() is pretty bad as well.
>> 
>> *Why* is it bad?
>
> Because there's no enforcement. You can copy most forward 
> ranges without using save, and it works EXACTLY the same. In 
> fact, most save implementations are {return this;}. If you ever 
> use a forward range that requires the use of .save to actually 
> copy it, you will have problems.
>
> So it essentially promotes generic code that is incorrect, but 
> works fine for most cases. I'm positive there are still cases 
> like this in Phobos. It's very easy and effortless to make a 
> copy without using .save.
>
> When's the last time you saw:
>
> foreach(x; someLvalueRange.save)
>
> Because if you don't see that, for a forward range, it's an 
> incorrect usage.

In that case, making input ranges non-copyable *may* indeed be a 
solution.