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

[Paul Backus]

On Monday, 22 June 2020 at 22:36:05 UTC, Aliak wrote:
> On Monday, 22 June 2020 at 22:17:43 UTC, Paul Backus 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()). Surely that's a 
>> better solution than implicitly inserting calls to arbitrary 
>> user-defined code every time someone passes an argument to a 
>> function.
>
> Can you use the tail() approach and keep the efficiency of 
> popFront? - I.e. do you see that if tail is const it returns a 
> newly constructed range and if tail() is mutable it can 
> internally call a popFront links think and return a ref to 
> itself?

In a world where tail() is a range primitive, popFront becomes an 
algorithm:

void popFront(R)(ref R r)
     if (isInputRangeV2!R && isMutable!R)
{
     r = r.tail;
}

Any decent optimizer should be able to turn this into a mutation. 
Since ranges already rely heavily on optimization to produce 
efficient code, I don't think it's unreasonable to rely on it 
here as well.

Of course, if you need more control, you are always free to 
specialize the algorithm for your own range type by defining a 
popFront method.