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

Paul Backus snarwin at gmail.com
Wed Jun 24 13:14:22 UTC 2020


On Wednesday, 24 June 2020 at 11:49:11 UTC, Stanislav Blinov 
wrote:
> On Monday, 22 June 2020 at 16:03:54 UTC, Andrei Alexandrescu 
> wrote:
>> 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);

IMO if the user has to manually call `move`, you have already 
failed at usability.

It may seem "easy" or "obvious" to you and I, but for beginners, 
this is going to be a huge stumbling block. You write some code 
that looks like it should obviously work, you get a mysterious 
error message that "std.algorithm.whatever!(some, args).Result is 
not copyable because it is annotated with @disable", and the 
solution is that you have to add ".move" to your code? Can you 
imagine having to explain that to someone in the Learn forum? I 
don't think I could do it with a straight face--it's too absurd.

The only way non-copyable input ranges can work is if the 
compiler is able to implicitly move them in cases like the above. 
In other words, we would need something like Walter's "Copying, 
Moving, and Forwarding" DIP [1].

[1] 
https://github.com/WalterBright/DIPs/blob/13NNN-WGB.md/DIPs/13NNN-WGB.md


More information about the Digitalmars-d mailing list