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

[Aliak]

On Monday, 22 June 2020 at 22:17:43 UTC, Paul Backus wrote:
> On Monday, 22 June 2020 at 21:46:51 UTC, Andrei Alexandrescu 
> wrote:
>> On 6/22/20 12:50 PM, Paul Backus wrote:
>>> 
>>> The trick used for arrays does not only apply to function 
>>> calls:
>>> 
>>>      const(int[]) a = [1, 2, 3];
>>>      const(int)[] b = a; // compiles
>>
>> That's different - it's an implicit conversion.
>>
>>> IMHO the principled way to allow user-defined implicit 
>>> conversions is...to allow user-defined implicit conversions. 
>>> But iirc that's a can of worms Walter prefers not to open.
>>
>> What happens upon function calls is not an implicit 
>> conversion. It's a forced type change.
>
> So what you're saying is, it's even *less* principled than I 
> thought? :)

Have you guys seen the work done here: 
https://gist.github.com/Biotronic/940f553fa1b4cbf80a98afe3d1970c6d ?

It is essentially the opOnCall with details on the library 
implementation as well.

>
> 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?