D's policy on hidden memory allocations and nothrow @nogc

[Adam D. Ruppe]

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.