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

[Stanislav Blinov]

On Wednesday, 24 June 2020 at 16:17:58 UTC, Andrei Alexandrescu 
wrote:
> On 6/24/20 11:55 AM, Paul Backus wrote:
>> To be clear: I agree with you *in principle* that pure input 
>> ranges should be non-copyable.
>
> By what principle two input ranges should absolutely never use 
> the same data feed?

By no principle. If a given data feed can be used in such manner 
- then used it shall be. By two distinct input ranges that keep 
their own state and don't breed references to said state.

> I'm not sure, but with a no-quarter-given approach to copying 
> input ranges, simple tasks      like "feed input from this 
> file, or from stdin, and output to this other file or to 
> stdout" mutate from trivial into little research projects

I don't see how. This and everything of the same simplicity stays 
exactly the same:

import std.stdio, std.array, std.algorithm;

void main()
{
     stdin
         .byLine
         .map!"a.length"
         .each!writeln;
}

Alleged issues materialize when you start using lvalues. Which 
I've already shown an example of a few posts back.

Does a CsvReader really need to allocate, especially if my data 
is numbers? The answer in current incarnation of ranges is "yes". 
Well then, I'd rather write one that doesn't. Thanks but no 
thanks, Phobos.

> (btw by the same (misguded imho) arguments "pure" output ranges 
> ought to also be noncopyable).

Perhaps.