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

[Steven Schveighoffer]

On 6/20/20 3:16 PM, Stanislav Blinov wrote:
> On Saturday, 20 June 2020 at 18:26:43 UTC, Steven Schveighoffer wrote:
>> On 6/20/20 8:30 AM, Stanislav Blinov wrote:
> 
>>> I can imagine this would be quite some work to adapt all of Phobos to 
>>> *that*. I mean, things like
>>>
>>> auto rem = makeSomeInputRange.find!pred;
>>> auto flt = makeSomeInputRange.filter!pred;
>>>
>>> Those would not compile. They could be made to compile by `move`ing 
>>> the argument for the return. But then you still won't be able to pass 
>>> those results around, unless via a refRange or `move`.
>>
>> You shouldn't need move for rvalues, which those should be. Algorithms 
>> that support non-forward ranges should be able to cope with using move 
>> where required on their parameters.
> 
> `find` returns the remainder of the range, i.e it's (pseudocode):
> 
> auto find(alias pred,R)(R r)
> {
>      while (!r.empty && !pred(r.front))
>          r.popFront;
>      return r;
> }
> 
> 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.

> It *may* become a move under Walter's proposal:
> 
> auto find(alias pred,R)(return R r)
> {
>      while (!r.empty && !pred(r.front))
>          r.popFront;
>      return r; // return what's called a `move ref` in the proposal
> }
> 
> but until then?..

You'd have to modify Phobos.

> 
>> 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.

> 
>> 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.

-Steve