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?

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?

I think even C malloc should be considered pure. True, it affects global state by allocating memory, but it never changes existing values, it just allows for new values. free is pure because it isn't side-effecting, it deallocates what you give it. That's just my perspective on it though, others might have other views on it.

On Wed, 14 May 2014 22:42:46 +0000
Brian Schott via Digitalmars-d <digitalmars-d@puremagic.com> 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?

I think malloc should definitely be considered pure for the same reasons that new is considered pure. I don't know about the other memory management functions though. I'd really have to think through their side effects to have an opinion on them. If we can make them pure though, that would certainly help with ensuring that allocators can be pure.

- Jonathan M Davis

On 5/14/2014 3:42 PM, Brian Schott wrote:
> If malloc can never be considered pure, even when hidden behind an allocator,

It cannot be pure as long as it can fail.

> why can it be considered pure when hidden behind the GC?

Because GC failures are not recoverable, so the pure allocation cannot fail.

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

On Thursday, 15 May 2014 at 00:00:37 UTC, Walter Bright wrote:
> On 5/14/2014 3:42 PM, Brian Schott wrote:
>> If malloc can never be considered pure, even when hidden behind an allocator,
>
> It cannot be pure as long as it can fail.
>
>> why can it be considered pure when hidden behind the GC?
>
> Because GC failures are not recoverable, so the pure allocation cannot fail.

Malloc is a tricky case. The results it returns are theoretically always unique, and it is referentially transparent if we pretend that we have infinite memory.

On Thursday, 15 May 2014 at 00:00:37 UTC, Walter Bright wrote:
> On 5/14/2014 3:42 PM, Brian Schott wrote:
>> If malloc can never be considered pure, even when hidden behind an allocator,
>
> It cannot be pure as long as it can fail.
>
>> why can it be considered pure when hidden behind the GC?
>
> Because GC failures are not recoverable, so the pure allocation cannot fail.

Can we say that Mallocator failures are not recoverable?

On 5/14/2014 5:44 PM, Brian Schott wrote:
> Can we say that Mallocator failures are not recoverable?

malloc itself does not have that property. But you could design a wrapper for it that did.

On 5/14/2014 5:03 PM, Meta wrote:
> Allocating memory through new and malloc should always be pure, I think, because
> failure either returns null in malloc's case,

malloc cannot be pure if, with the same arguments, it returns null sometimes and not other times.


> or throws an error in new's case.

A non-recoverable error.
  ^^^^^^^^^^^^^^^

On Thursday, 15 May 2014 at 00:50:06 UTC, Walter Bright wrote:
> On 5/14/2014 5:03 PM, Meta wrote:
>> Allocating memory through new and malloc should always be pure, I think, because
>> failure either returns null in malloc's case,
>
> malloc cannot be pure if, with the same arguments, it returns null sometimes and not other times.
>
>
>> or throws an error in new's case.
>
> A non-recoverable error.
>   ^^^^^^^^^^^^^^^

If we pretend that there's infinite memory, then malloc will never return null.