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

[Steven Schveighoffer]

On 6/22/20 10:55 AM, Paul Backus wrote:
> 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).
>>
> 
> 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 don't see a difference. When you copy a range as a parameter, the head 
is a different piece of memory. This is why it works. Why is it 
important how it works?

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

That isn't why tail-const was "introduced". And I would consider 
enabling this feature for custom types fixing it at the source.

Why does it seem backwards to you?

Perhaps you are thinking of how templates automatically strip the head 
const? That I don't necessarily agree with either, but there isn't a 
good way to say "take this parameter as head-mutable" in generic code, 
which is why *that* was added. If we did have a mechanism to say that 
(such as FeepingCreture's `headmut` example), then we wouldn't need that 
special treatment.

-Steve