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

Stanislav Blinov stanislav.blinov at gmail.com
Sat Jun 20 19:16:57 UTC 2020


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 :) 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?..

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

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


More information about the Digitalmars-d mailing list