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

[Stanislav Blinov]

On Sunday, 21 June 2020 at 14:47:55 UTC, Andrei Alexandrescu 
wrote:

> I appreciate there's no shortage of people who teach my design 
> and my code back to me. I honestly do, a lot.

And I, in turn, appreciate that you nicked one paragraph and 
ignored (I assume dismissed) everything else. Very motivating.

> It's unclear that much of anything, was demonstrated. Was the 
> better alternative to make input ranges noncopyable?

No. No. No. It wasn't an alternative to your API. We weren't even 
discussing a completely alternative API until you threw it in.
I compared of two APIs in terms of operations. But "nothing was 
demonstrated". OK! Anyway, the whole discussion was going around 
the existing API, and either:

- input ranges non-copyable and forward ranges are, or
- status quo (i.e. save() for forward ranges)

I didn't catch on the distinction initially, when H.S. brought up 
the save(); now I do.

TLDR for all of the below - under either API, input ranges being 
non-copyable is a much better choice.

Input ranges, by nature being one-pass, *should not be copyable*. 
You can't do anything (good) with a copy, and have to invest into 
implementing a copy that won't bite. If you're giving such range 
away - you're giving it *away*, to someone else to consume. It 
being copyable only means that you're leaving for yourself a 
mutable reference to state that you shouldn't touch again. When 
you need the remainder back - your callee will move it back.

You mentioned the "smell" of ByLine. A good deal of that "smell" 
emanates from its copy-ability. I mean, disabling a constructor 
versus reference-counted internals - which plate is heavier?... 
Using either API, that smell will stay if it is to remain 
copyable.

Most of the time you'd be using input ranges as rvalues. In the 
remaining cases the compiler will give you an error if you try to 
copy - and that's a good error.

> It only takes a couple of hours of coding a bit of that up to 
> see it's quite onerous.

It isn't. Bugs in the language and Phobos aside - it's one `move` 
away.

Here, a few Phobos algorithms implemented with the `fetchNext` 
API:

https://gist.github.com/radcapricorn/d76d29c6df6fa822d7889e799937f39d

The good? An actual source range (ByLine) is 
dumb-as-a-cork-simple. No buffering, no ref-counted internals: 
read, slice, rinse and repeat. The bad? Well, you can see for 
yourself.