Memory allocation purity

[Meta via Digitalmars-d]

On Wednesday, 14 May 2014 at 22:42:47 UTC, Brian Schott wrote:
> What is the plan for the "pure"-ity of memory management?
>
> Right now the "new" operator is considered to be pure even 
> though it is not, but related functinos like malloc, 
> GC.addRange, GC.removeRange, and others are not.
>
> This prevents large portions of std.allocator from being pure. 
> This then prevents any containers library built on 
> std.allocator from being pure, which does the same for any 
> funcions and data structures written using those containers.
>
> If malloc can never be considered pure, even when hidden behind 
> an allocator, why can it be considered pure when hidden behind 
> the GC?

Allocating memory through new and malloc should always be pure, I 
think, because failure either returns null in malloc's case, or 
throws an error in new's case. As for GC.addRange, 
GC.removeRange, etc... it's hard to say. These functions 
definitely alter the state of the GC, but it's all wrapped up in 
the GC's black box, guaranteed to never escape (I think? I don't 
know exactly how they're implemented). In the general case, as 
long as side-effects can be guaranteed to never affect anything 
outside of a function/class/struct, I think it can probably be 
pure (D's notion of purity, anyway).