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 14:33:53 UTC, Steven Schveighoffer 
wrote:
> On 6/22/20 10:20 AM, Paul Backus wrote:
>> 
>> Well, currently, range algorithms can't work with const ranges 
>> *at all*, recursively or iteratively. So from a user 
>> perspective, this would be a strict improvement on the status 
>> quo.
>
> Algorithms can work with const ranges -- as long as the range 
> is an array:
>
> const int[] arr = [1, 2, 3, 4, 5];
>
> auto x = arr.find(3);
>
> assert(x == [3, 4, 5]);
>
> I think the better option is to focus on making it possible to 
> duplicate this possibility for generic ranges rather than 
> implement a new and awkward API.
>
> FeepingCreature is right, we should try and create a head 
> mutable mechanism. I have envisioned it in the past as a 
> tail-modifier mechanism (e.g. tail-const).
>
> -Steve

This isn't really "algorithms working with const ranges"; rather, 
it's "const(T[]) implicitly converts to const(T)[]". The 
algorithm itself never sees a const range.

I suppose we could have the same thing for user-defined types if 
we added `@implicit opCast`, or a more restrictive version like 
`opHeadMutable`, but the whole thing seems backwards to me. 
const(T[]) converting to const(T)[] is a special case in the 
language introduced to compensate for the shortcomings 
`popFront`. Rather than doubling down on it, why not fix the 
issue at its source?