Question to GC experts: NO_SCAN for a part of the block

[Stanislav Blinov via Digitalmars-d]

On Tuesday, 6 June 2017 at 09:57:31 UTC, Steven Schveighoffer 
wrote:

>>> Note that p[0 .. sz] is treated as an opaque range of memory 
>>> assumed to be suitably managed by the caller. In particular, 
>>> if p points into a GC-managed memory block, addRange does not 
>>> mark this block as live.
>>
>> Is that paragraph wrong?
>
> No I am wrong. I assumed that because the gc is part of the 
> static space it's metadata would also be scanned. But the data 
> is allocated using c malloc, so it's not scanned. This makes 
> any partial insertion using addrange more dangerous actually 
> because you have to take care to keep a pointer to that block 
> somewhere

You mean explicitly pointer to the block itself? It is being kept 
with the first array.
Or you mean the pointer passed to addRange? That one would not 
necessarily belong to the first array. But I thought the GC does 
track pointers that point to block interiors. After all, that's 
how slices work.

>> Then it's just the obvious() function. The whole point of the 
>> exercise is to make one GC allocation instead of N :) But 
>> still GC, so as not to put additional responsibility on the 
>> caller.
>
> No, 2 allocations instead of N.

In this example. But obviously I'd like to make this generic, 
i.e.:

struct S { /* ... */ }

auto arrays = allocateArrays!(int, "ints", numInts, S, "Ss", 
numSs, void*, "pointers", numPtrs);

So it won't necessarily be 2. And of course the function would 
calculate the alignment, initialize the contents (or not, e.g. 
via passing a dummy type Uninitialized!T), etc.

I do have a use case for allocating up to 4 arrays at once, for 
example.