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

[Paul Backus]

On Tuesday, 23 June 2020 at 05:15:49 UTC, Andrei Alexandrescu 
wrote:
>> Regardless, my broader point is that once we're open to the 
>> possibility of designing a new range API, all of this can be 
>> solved without any language changes by using an API that 
>> doesn't require mutation (i.e., tail()).
>
> Using only tail() makes iteration with mutable ranges 
> inefficient

I don't think it's a given that tail() is less efficient than 
popFront(). Here's a program where both tail() and popFront() 
produce the same assembly with `ldc -O2`:

https://d.godbolt.org/z/-S_JoF

Of course, if it does turn out to make a difference in some 
cases, mutable ranges are free to implement popFront as well. 
There will be a generic version in std.v2.algorithm to ensure 
that `mutableRange.popFront()` is always valid.

> and iteration with immutable ranges difficult (must use 
> recursion everywhere). Hardly a winner of a design contest.

Even if we assume for the sake of argument that "recursion == 
difficult", I would still say that "difficult" is an improvement 
over "impossible".