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

Paul Backus snarwin at gmail.com
Mon Jun 22 16:14:33 UTC 2020


On Monday, 22 June 2020 at 15:47:51 UTC, Steven Schveighoffer 
wrote:
> On 6/22/20 10:55 AM, Paul Backus wrote:
>> 
>> 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?

It's important how it works because it *doesn't* work, for ranges 
in general. It only works for slices.

Making it work in general requires either subverting the type 
system (like Rebindable does) or adding more special cases to the 
language.

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

The question is, why do you need a mechanism to say that in the 
first place? Why not just have generic code take the argument as 
its actual type?

Answer: because popFront requires a mutable object.

`headmut` is a solution to a problem that doesn't need to exist 
in the first place. Get rid of popFront, and you get rid of the 
problem.


More information about the Digitalmars-d mailing list