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

[Steven Schveighoffer]

On 6/20/20 8:30 AM, Stanislav Blinov wrote:
> On Saturday, 20 June 2020 at 11:20:13 UTC, Petar Kirov [ZombineDev] wrote:
> 
>> As far as I know, back when the ranges API was worked on postblit 
>> ctors didn't work reliably, so .save() was the only option.
> 
> Funny that, at the moment it's the copy ctors that aren't working 
> reliably (e.g. they're not working at all with arrays). :)
> 
>> If it had worked, we could require that non-forward ranges are 
>> non-copyable.
> 
> 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.

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.

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.

-Steve