I'm proposing that std.experimental.allocator.make, as well as
its friends, throw an exception when the allocator cannot satisfy
a request instead of returning null.
These are my reasons for doing so:
* It eliminates the incredibly tedious, annoying, and
easy-to-forget boilerplate after every allocation to check if the
allocation succeeded.
* Being unable to fulfill an allocation is an exceptional case
[1], thus exceptions are a good tool for handling it. Performance
on the out-of-memory case isn't a big issue; 99% of programs,
when out of memory, either exit immediately or display an "out of
memory" message to the user and cancel the operation.
* 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).
* Creating a standard out-of-memory exception will make it easier
to catch, instead of catching each library's own custom exception
that they will inevitably define.
Hopefully, since std.experimental.allocator is experimental,
we'll be allowed to make such backwards-incompatible changes.
What are other peoples thoughts on this? Or has this brought up
before and I missed the discussion?
[1] It may not be very exceptional for "building-block"
allocators that start with small but fast allocators that may
fail a lot, in which case returning null is appropriate. However,
AFAIK allocators internally use the `allocate` method of the
allocator, not make, et al., so they should be unaffected by this
change.
