After having read up on Zig's [1] policy for memory management, basically meaning no syntactically hidden memory allocations, I wonder if D has something similar.

Is the praxis that _all_ containers and GC-allocations should throw a

    core.exception.OutOfMemoryError

upon out of memory error?

If so should all algorithms that potentially allocates memory be non-`nothrow`, and in turn, non-`@nogc`?

And how does this relate to instead using `assert`s and DIP-1008?

[1]: https://ziglang.org/

On Wednesday, 5 September 2018 at 20:53:41 UTC, Per Nordlöw wrote:
> Is the praxis that _all_ containers and GC-allocations should throw a

yeah, but do so via the onOutOfMemoryError function instead of "throw new"

http://dpldocs.info/experimental-docs/core.exception.onOutOfMemoryError.html


well, unless you actually have a recoverable out of memory situation, then you might want to do it differently (e.g. a pool runs out of memory, then you might return null or something and handle it at a higher level)

But...

> If so should all algorithms that potentially allocates memory be non-`nothrow`, and in turn, non-`@nogc`?

No, it doesn't affect either of those.

It doesn't affect @nogc because the function above will throw a statically-allocated object instead of creating a new one (if it is out of memory, where would it allocate a new one anyway?).

It doesn't affect nothrow because it is considered a fatal Error instead of a recoverable Exception.

> And how does this relate to instead using `assert`s and DIP-1008?

assert works by similar rules and is thus unaffected by those things too.

On Wednesday, 5 September 2018 at 21:06:07 UTC, Adam D. Ruppe wrote:
> It doesn't affect @nogc because the function above will throw a statically-allocated object instead of creating a new one (if it is out of memory, where would it allocate a new one anyway?).
>
> It doesn't affect nothrow because it is considered a fatal Error instead of a recoverable Exception.
>
>> And how does this relate to instead using `assert`s and DIP-1008?
>
> assert works by similar rules and is thus unaffected by those things too.

Thanks!