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

[Era Scarecrow via Digitalmars-d]

On Wednesday, 20 April 2016 at 21:26:12 UTC, Alex Parrill wrote:
> This would be best implemented in a "building block" allocator 
> that wraps a different allocator and uses the 'allocate' 
> function, making it truly optional. It would also need a 
> timeout to fail eventually, or else you possibly wait forever.

  I'd say either you specify the amount of retries, or give some 
amount that would be acceptable for some background program to 
retry for. Say, 30 seconds.

>> Although IF the memory could be rearranged and a second 
>> attempt made before deciding to throw could be useful
> This is the mechanism used for "copying" garbage collectors. 
> They can only work if they can know about and alter all 
> references to the objects that they have allocated, which makes 
> them hard to use for languages with raw pointers like D.

I was thinking more along the lines of having a slot with the 
memory data and you never take the pointer address, using 
everything through the API. As long as nothing is shared between 
threads and there are no pointers in the data then 
realigning/compacting memory is fine. But then there's a 
potential speed cost if there's a lot to work with.