Bug 23318 – GCAllocator should not implement deallocate

Currently, a container instantiated using GCAllocator is not usable in @safe code: --- /+dub.sdl: dependency "emsi_containers" version="~>0.9.0" +/ import containers.dynamicarray; import std.experimental.allocator.gc_allocator; void main() @safe { auto a = DynamicArray!(int, GCAllocator)(); } --- Attempting to compile the above program produces the following error message: --- onlineapp.d(9,10): Error: `@safe` function `D main` cannot call `@system` destructor `containers.dynamicarray.DynamicArray!(int, GCAllocator, false).DynamicArray.~this` --- The destructor is @system because it calls GCAllocator.deallocate, which in turn calls GC.free [1]--in other words, because the container is freeing its memory manually, rather than relying on the GC to free it automatically. Since GCAllocator is intended to be std.experimental.allocator's interface to D's built-in GC, it should match the behavior of the GC as closely as possible. In particular, a container instantiated with GCAllocator should behave the same way as a container that allocates with `new` directly w.r.t. memory management. Such a container would *not* free its memory manually on destruction. To resolve this inconsistency, GCAllocator.deallocate should be removed. [1] https://github.com/dlang/phobos/blob/v2.100.1/std/experimental/allocator/gc_allocator.d#L89-L93

@pbackus created dlang/phobos pull request #8555 "Add GCHeapMallocator" mentioning this issue: - Add GCHeapMallocator It has been proposed to change the behavior of GCAllocator to more closely match that of the built-in GC (in particular, to make it @safe). In preparation for that change, this change makes the original behavior of GCAllocator available under a new name, GCHeapMallocator. When GCAllocator is changed, users may choose to either adopt the new behavior or migrate to GCHeapMallocator and retain the original behavior. For the rationale behind these changes, see PR #8554 and issue 23318. https://github.com/dlang/phobos/pull/8555

As I mentioned in DConf2022, I'm not sure GCAllocator should even exist.What would be the point of a dynamic array explicitly requesting the GC?

> What would be the point of a dynamic array explicitly requesting the GC? Under what circumstances would a user of a generic container want to instantiate that container such that it uses the GC? Presumably the same circumstances under which users currently use containers like the ones in std.container that hard-code a dependency on the GC. It seems obvious and sensible to me that a generic, allocator-aware container library should be able to offer a strict superset of the functionality currently offered by our GC-only std.container library. That means the allocator library should make the GC available as an option, and the obvious way to do that is via GCAllocator.

@pbackus updated dlang/phobos pull request #8554 "Remove deallocate and reallocate from GCAllocator" fixing this issue: - Remove GCAllocator.deallocate This is necessary to make clients of GCAllocator (e.g., generic containers) usable in @safe code. Memory allocated by GC allocator will still be freed by the GC when it is no longer reachable. Rejected alternatives: - Making GCAllocator.deallocate a no-op method that always returns false. The documentation in std.experimental.allocator.building_blocks specifically says not to do that. - Special-casing client code for GCAllocator to avoid calling its 'deallocate' method, while still calling 'deallocate' for other allocators. 'deallocate' has been documented as an optional method since std.experimental.allocator was introduced in 2015 (commit 8b249a6240), so this change will not break code that correctly adheres to the documented allocator interface (i.e., checks for the presence of 'deallocate' before calling it). Fixes issue 23318. https://github.com/dlang/phobos/pull/8554

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/phobos/issues/10497 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB