Specifying @nogc on structs seems to have no effect

[B4s1L3]

On Tuesday, 19 September 2017 at 13:11:03 UTC, Craig Black wrote:
> I've recently tried coding in D again after some years.  One of 
> my earlier concerns was the ability to code without the GC, 
> which seemed difficult to pull off.  To be clear, I want my 
> programs to be garbage collected, but I want to use the GC 
> sparingly so that the mark and sweep collections will be fast.  
> So I want guarantees that certain sections of code and certain 
> structs will not require the GC in any way.
>
> I realize that you can allocate on the non-GC heap using malloc 
> and free and emplace, but I find it troubling that you still 
> need to tell the GC to scan your allocation. What I would like 
> is, for example, to be able to write a @nogc templated struct 
> that guarantees that none of its members require GC scanning.  
> Thus:
>
> @nogc struct Array(T)
> {
>   ...
> }
>
> class GarbageCollectedClass
> {
> }
>
> void main()
> {
>   Array!int intArray; // fine
>
>
> }

I've implemented data annotation in iz, if you want to take a 
look.
It's quite near from what you descibed in a more recent answer:

----
/+ dub.sdl:
    name "dub_script"
    dependency "iz" version="0.6.0"
+/
module dub_script;

import iz.memory;

// defines a class that has a member
// which is usually handled by the GC
class Foo {void* looks_gc_managed;}
// defines a class and marks member as nogc-"trusted"
class Bar {@NoGc Foo foo;}
// defines a class without annotation
class Baz {Foo foo;}

// verified statically
static assert(!MustAddGcRange!Bar);
static assert( MustAddGcRange!Baz);

void main(string[] args)
{
     Foo foo = construct!Foo;
     destruct(foo);
}
----

It's another way of doing things. It's less strict than checking 
all the functions.

note: the script can be run directly by passing the file to DUB 
(single file package).