Store mutable indirections in immutable data with this one weird trick!

[Dukc]

On Saturday, 13 November 2021 at 18:06:37 UTC, Ola Fosheim 
Grøstad wrote:
> On Saturday, 13 November 2021 at 15:16:43 UTC, Paul Backus 
> wrote:
>> What you do is have the compiler enforce the preconditions 
>> necessary to make its assumptions hold. So, if the result of a 
>> `pure` function is not supposed to depend on the specific 
>> values of any pointers, `pure` functions should be forbidden 
>> from comparing pointers, casting them to integers, or 
>> performing any other operations that might introduce such a 
>> dependency.
>
> That would undermine performance and render pure even more 
> useless than it already is.

Not at all. He suggested having the compiler to catch the 
mistakes, not the runtime.

I'm all in for that, if we can find ways which don't break too 
much valid code. I'm not sure that is possible though.

> Just remove the notion of normative "strongly pure", it is a 
> big mistake to split a concept based on the input typing. 
> Confusing two concepts like this in one construct is making the 
> language more complex than keeping the concepts separate. It is 
> ugly. Keep it clean, keep semantics of each concept simple.

I'm assuming you mean that the language would allow caching 
values even with arguments with mutable indirection, if the 
compiler can prove they are similar to an earlier call. I agree 
but that will do nothing to solve the issue (repeated calls to 
functions being wrongly skipped because accidently misusing 
`pure`). Rather the problem will be magnified.

Well, I almost agree. The problem is that [`free` would 
break](https://issues.dlang.org/show_bug.cgi?id=22277).