GC.addRange in pure function

[Petar]

On Friday, 12 February 2021 at 12:17:13 UTC, Per Nordlöw wrote:
> On Tuesday, 9 February 2021 at 03:05:10 UTC, frame wrote:
>> On Sunday, 7 February 2021 at 14:13:18 UTC, vitamin wrote:
>>> Why using 'new' is allowed in pure functions but calling 
>>> GC.addRange or GC.removeRange isn't allowed?
>
> Would making
>
> `new T[]` inject a call to `GC.addRange` based on `T` (and 
> maybe also T's attributes)
>
> be a step forward?

`GC.addRange` is only used for memory allocated outside of the GC 
that can hold references to GC allocated objects. Since `new T[]` 
uses the GC, all the information is typeinfo is already there 
(*), so `GC.addRange` is unnecessary and even wrong, because when 
the GC collects the memory it won't call `GC.removeRange` on it

Implementation-wise, metadata about GC-allocated memory is held 
in the GC internal data structures, whereas the GC roots and 
ranges are stored in separate malloc/free-managed containers.

(*) Currently `new T[]` is lowered to an `extern (C)` runtime 
hook and the compiler passes to it typeid(T). After this the call 
chain is: _d_newarray_d_newarray{T,iT,mTX,miTX} -> _d_newarrayU 
-> __arrayAlloc -> GC.qalloc -> ConservativeGC.mallocNoSync -> 
Gcx.alloc -> {small,big}Alloc -> setBits