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

--- Comment #1 from Dlang Bot <dlang-bot@dlang.rocks> ---
@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

--

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

Atila Neves <atila.neves@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |atila.neves@gmail.com

--- Comment #2 from Atila Neves <atila.neves@gmail.com> ---
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?

--

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

--- Comment #3 from Paul Backus <snarwin+bugzilla@gmail.com> ---
> 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.

--

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

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #4 from Dlang Bot <dlang-bot@dlang.rocks> ---
@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

--

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--