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