https://issues.dlang.org/show_bug.cgi?id=23090

          Issue ID: 23090
           Summary: Allocators should not use NullAllocator as a sentinel
                    type
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: phobos
          Assignee: nobody@puremagic.com
          Reporter: snarwin+bugzilla@gmail.com

Several allocators in std.experimental.allocator have special-case behavior when instantiated using the specific type `NullAllocator`.

A non-exhaustive list:

* Region: "If ParentAllocator is different from NullAllocator, Region deallocates the chunk of memory during destruction." [1]

* ContiguousFreeList: "The block is assumed to have been allocated with ParentAllocator, and is released in ContiguousFreeList's destructor (unless ParentAllocator is NullAllocator)." [2]

* AllocatorList: "If BookkeepingAllocator is NullAllocator, then AllocatorList is "ouroboros-style", i.e. it keeps the bookkeeping data in memory obtained from the allocators themselves." [3]

It is clear from these examples that the type `NullAllocator` is being used as a sentinel to indicate the *absence* of an allocator, rather than for its actual documented purpose of being an allocator that is always out of memory.

This abuse of NullAllocator has two undesirable consequences:

1. Users who want NullAllocator's out-of-memory behavior must define their own
version with a different name, rather than using NullAllocator directly.
2. Readers of the std.experimental.allocator documentation are likely to come
away confused about NullAllocator's purpose.

[1] https://dlang.org/library/std/experimental/allocator/building_blocks/free_list/contiguous_free_list.html [2] https://dlang.org/library/std/experimental/allocator/building_blocks/free_list/contiguous_free_list.html [3] https://dlang.org/library/std/experimental/allocator/building_blocks/allocator_list/allocator_list.html

--