On Tuesday, 18 September 2018 at 23:01:46 UTC, Per Nordlöw wrote:
> On Tuesday, 18 September 2018 at 14:23:44 UTC, 9il wrote:
>> I just remember that D's GC has NO_SCAN [1] attribute!
>
> I thought D libraries like Mir and Lubeck only had to care about when to call GC.addRange after allocations that contain pointers to GC-backed storage and GC.removeRange before their corresponding deallocations. But that's perhaps only when using non-GC-backed allocators (not using new), right?

GC.addRange and GC.removeRange are necessary to mark memory blocks allocated outside of the GC when they may contain pointers to memory allocated by the GC.

For example, if you have a @nogc container, the array backing the container can allocated vie libc's malloc. The users are free push elements allocated by the GC on this container, so to be safe, the container must use GC.addRange to tell the GC that the array may point to such elements. When the array grows, shrinks or the whole container is destoryed, the array needs to be passed to GC.removeRange, so the GC would be prevented from scanning freed memory.

When you use the GC it automatically does the book keeping for you. It's only when you manually manage memory that you need to be careful whether this memory points to GC objects.