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: nob...@puremagic.com Reporter: snarwin+bugzi...@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 --