How to fake pure

Dom DiSc dominikus at scherkl.de
Tue Apr 8 16:41:38 UTC 2025


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


More information about the Digitalmars-d-learn mailing list