Store mutable indirections in immutable data with this one weird trick!
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Sat Nov 13 21:26:46 UTC 2021
On Saturday, 13 November 2021 at 18:55:11 UTC, Dukc wrote:
> Not at all. He suggested having the compiler to catch the
> mistakes, not the runtime.
He argued against using identity and relying fully on content,
that is crazy expensive in common situations/algorithms.
This is not practical in a language where you expect to use
library abstractions. As such, you end up not being able to use
"pure" for anything that is non-trivial.
> 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.
If we want the programmer to use "proper purity" for caching
values in libraries then it should be a separate construct that
is enforcing norms on the program that are stronger than the
regular "weakly pure". It should have a different syntax and very
clear normative standards so people understand the difference.
Meaning dealing rigorously with termination, nontrivial
destructors, exceptions, allocations etc etc. If not able to deal
with it rigorously: ban those constructs. Compiler type system
should err on the side of correctness.
If you want the compiler to cache values, then it should just be
based on static analysis of weakly pure. Compiler optimisation
should err on the side of correctness.
But saying that "weakly pure" syntax with immutable input is
providing a different set of semantics that somehow evolve over
time on some sort of slippery slope is likely to lead up to a
mess.
Just stick to the keyword ```pure``` meaning "no globals", and
leave it at that. Want more? Introduce a new well defined concept.
More information about the Digitalmars-d
mailing list