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

[Stanislav Blinov]

On Monday, 22 June 2020 at 16:03:54 UTC, Andrei Alexandrescu 
wrote:
> On 6/21/20 1:43 PM, Stanislav Blinov wrote:
>> Input ranges, by nature being one-pass, *should not be 
>> copyable*...

> Good arguments, no doubt, but a long experience with 
> noncopyable C++ objects suggests that defining such types need 
> to be approached with trepidation as they are very cumbersome 
> to use.

In C++ - traditionally they were cumbersome, even to define, 
until move came along. In D though? The biggest annoying obstacle 
is Phobos making lots of redundant copies, needlessly prohibiting 
the use of non-copyables. That, however, is not a fault of 
non-copyables, but of Phobos.
The GC limits the use of non-copyables for sure, though that's 
largely irrelevant to ranges themselves, esp. considering that 
classes indeed shouldn't ever be ranges.

> (Any type containing a noncopyable type as a member becomes 
> itself noncopyable;

And that is *good*.

> this is not something that we can inflict lightly on the casual 
> users of input ranges.

That is exactly what we *should* inflict on "casual" users. 
Compile-time errors. For trying to casually write bugs.

> (To wit: no input streams or iterators in C++ are noncopyable, 
> although the same argument would apply to them as well.)

An input range being non-copyable is immensely beneficial - it 
would statically catch a good deal of problems. It would 
*alleviate* the need of added complexity in implementations. 
Looking back at the ByLine again: RefCounted internals just to 
remain copyable. I don't think appeasing "casual users" by 
over-engineering is a good compromise.
Non-copyables in D are easy to write, easy to use *correctly*, 
and difficult to use *incorrectly* (won't compile, after all).

> Also, it is not unheard of to have two input ranges fed from 
> the same source with the obvious semantics (whoever calls 
> functions to get more data will get the data and push the 
> cursor further). True, buffering is an issue (what if two 
> copies have each their own buffers?) but that's an engineering 
> problem, not one of principles.

That would be different instances of input ranges over the same 
source, not copies of the same range carrying unnecessary state 
and complexity (over-engineered solutions to the buffering 
issue). We're never consuming the same range *simultaneously* in 
different places. With an uncopyable, we'd just have to give it 
to a consumer and then have them give the remainder back to us.

> It is quite clear to me that we can't propose a design with 
> noncopyable input ranges without effectively making them 
> pariahs that everybody will take pains to use and do their best 
> to avoid.

Then we should propose a design that is not painful to use:

// error: `input` cannot be copied
// auto data = input.filter!somehow.map!something.array;
// Ok:
auto data = input.move.filter!somehow.map!something.array;

If we need partial consumption, i.e. preservation of the 
remainder, terminal primitives can give it back to us (after all, 
wrapping range is holding onto it):

auto data = 
input.move.filter!somehow.take(someAmount).map!something.array(input);

The implementation of such `array` would look like this:

auto array(Range, Remainder)(Range range, ref Remainder remainder)
if (isInputRange!Range && is(typeof(range.source) == Remainder))
{
     import std.array : appender;
     auto builder = appender!(ElementType!Range[]);
     // this is assuming current API, substitute with whatever 
replacement API
     while (!range.empty)
     {
         builder.put(range.front);
         range.popFront();
     }
     move(range.source, remainder);
     return builder[];
}

I wouldn't say this qualifies as "painful", to author or use. 
Authors of ranges would be writing ranges, and not the machinery 
required to keep them copyable. Users of ranges would be using 
ranges, and not the hidden machinery required to keep them 
copyable.