On Tuesday, 8 April 2025 at 15:54:52 UTC, Timon Gehr wrote:
In any case, casting a memory allocator to `pure` should be
fine. Any reasonable definition of `pure` we can come up with
in the future would be compatible with that.
Yes, this is also what I think. Of course an allocator cannot be
strongly pure, but it should keep away the mental burden of
memory management from the rest of a program. So I always thought
of "D pure" as something like "pure except for allocation".
Other exceptions from pure are much harder to defend and should
be avoided if possible - e.g. reliance on the memory-address of
objects is nothing I would consider "pure" - the allocator will
give me always different values, so this is a clear violation of
purity.
Garbage like
int foo() @safe pure { int x; return cast(int)&x; }
should not compile. But it does :-(
Maybe one could say, yes this is safe (also questionable), but it
is NOT pure. Never ever.
A pure function called with the same parameters should always
produce the same output, except of maybe aborting caused by
external reasons (which for me includes insufficient amount of
available memory and interrupts by the OS... and of course
user-interference).
