std.experimental.allocator.make should throw on out-of-memory

[Era Scarecrow via Digitalmars-d]

On Tuesday, 19 April 2016 at 22:28:27 UTC, Alex Parrill wrote:
> * It fails faster and safer. It's better to error out 
> immediately with a descriptive "out of memory" message instead 
> of potentially continuing with an invalid pointer and 
> potentially causing an invalid memory access, or worse, a 
> vulnerability, if the developer forgot to check (which is 
> common for boilerplate code).

  Guaranteeing that a returned call from requesting memory does 
make code simpler. I believe Java does this as well (although the 
default memory size wasn't as large as it needed to be :P )

  The downside though is the requirement to throw may not be 
necessary. Having a failed attempt at getting memory and sleeping 
the program for 1-2 seconds before retrying could succeed on a 
future attempt. For games this would be a failure to have the 
entire game pause and hang until it acquires the memory it needs, 
while non critical applications (say compressing data for a 
backup) having it be willing to wait wouldn't be a huge 
disadvantage (assuming it's not at the start and already been 
busy for a while).

  This also heavily depends on what type of memory you're 
allocating. A stack based allocator (with fixed memory) wouldn't 
ever be able to get you more memory than it has fixed in reserve 
so immediately throwing makes perfect sense; Although IF the 
memory could be arranged and a second attempt made before 
deciding to throw could be useful (which assumes not having 
direct pointers to the memory in question and rather having an 
offset which is used. The more I think about it though the less 
likely this would be).