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

[Andrei Alexandrescu]

On 6/23/20 9:07 AM, Paul Backus wrote:
> 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

With arrays, no problem. Two words to copy, easy to track, enregister 
etc. With elaborate ranges, definitely a problem.

> 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".

There's "onerous" somewhere in there, too. I agree with Steve who said 
implementing recursive variants of most range algorithms in Phobos would 
be onerous.

The each() primitive I discussed may work nice actually because it 
allows recursion to be done in only itself, instead of every algorithm.