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?

On Wednesday, 10 February 2021 at 16:25:44 UTC, Petar Kirov [ZombineDev] wrote:
> On Wednesday, 10 February 2021 at 13:44:53 UTC, vit wrote:
>> [...]
>
> TL;DR Yes, you can, but it depends on what "without problem" means for you :P
>
> [...]

Thanks,

Yes, I am implementing container (ref counted pointer). When allcoator is Mallcoator (pure allocate and deallocate) and constructor of Type inside rc pointer has pure constructor and destructor, then only impure calls was GC.addRange and GC.removeRange.
Now there are marked as pure.

On Friday, 12 February 2021 at 19:48:01 UTC, vitamin wrote:
> On Wednesday, 10 February 2021 at 16:25:44 UTC, Petar Kirov [ZombineDev] wrote:
>> On Wednesday, 10 February 2021 at 13:44:53 UTC, vit wrote:
>>> [...]
>>
>> TL;DR Yes, you can, but it depends on what "without problem" means for you :P
>>
>> [...]
>
> Thanks,
>
> Yes, I am implementing container (ref counted pointer). When allcoator is Mallcoator (pure allocate and deallocate) and constructor of Type inside rc pointer has pure constructor and destructor, then only impure calls was GC.addRange and GC.removeRange.
> Now there are marked as pure.

Great, that's the exact idea!

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