Specifying @nogc on structs seems to have no effect

[Neia Neutuladh]

On Tuesday, 19 September 2017 at 15:11:31 UTC, Craig Black wrote:
> Thank you for the information.  What I would like to do is to 
> create an Array template class that doesn't use GC at all.

You want to ensure that it can never refer to GC memory. The type 
system does not contain that information. It doesn't say whether 
an object was allocated on the GC heap, on the stack, using 
malloc, using a whole page of memory with mmap, using hardware 
addresses directly on an embedded system with manually planned 
memory layout, using a well-known address range like VGA, as part 
of the binary's static data segment...

So @nogc can't help you. You could, however, replace the GC 
implementation with one that throws an AssertError whenever the 
GC runs a collection, allocates memory, etc. Or you could just 
add @nogc to your main function.

If you want to forbid all reference types, you could write a 
`containsReferenceTypes` template, something like:

enum containsReferenceTypes(T) =
   is(T == class) ||
   is(T == interface) ||
   isDynamicArray!T ||
   isDelegate!T ||
   (isStruct!T && hasReferenceField!T);

bool hasReferenceField(T)()
{
   static foreach (t; Fields!T)
   {
     if (containsReferenceTypes!t) return true;
   }
   return false;
}

struct Array(T) if (!containsReferenceTypes!T)
{
}

> Unfortunately I don't think this is possible with D in its 
> current state, at least not safely anyway.  As it is, I can't 
> prevent someone using my Array template to create an array of 
> objects that reference the GC heap.  This means that in order 
> to not break the language and avoid memory leaks, I am forced 
> to tell the GC to scan all of my allocations.  There seems to 
> be no way to avoid this unnecessary overhead.

That's use-after-free, not memory leaks. The GC doesn't watch to 
see when things go out of scope; it periodically scans the world 
to see what's still in scope.

> I realize that the GC will not collect during a @nogc function.
>  This is a good guarantee, but I want to reduce the amount of 
> time it takes to perform a collection, and there doesn't seem 
> to be a good way to do this.

The GC is smart enough to not scan something for pointers if it 
doesn't contain pointers. So if you have `new Vec4[100]`, for 
instance, the GC isn't going to waste time scanning the memory it 
points to.

So if you have an Array!int variable in a GC'd object, it's 
basically a pointer and a length. The GC will note that the block 
of memory it points to has a reference to it and should not be 
disposed of. It will at some point consider doing a scan on that 
block of memory, see that it has no pointers in it, and skip over 
it.