Specifying @nogc on structs seems to have no effect

[Steven Schveighoffer]

On 9/19/17 2:06 PM, Craig Black wrote:
> Thank you for the clarification. I understand mow that @nogc is only for 
> functions and not for data types.  Thinking out loud, it would seem 
> beneficial if there was a way to mark a pointer or data structure as not 
> pointing to the GC heap. A guarantee to the compiler and run-time to 
> ignore it during GC sweeps.  Now I know that pointer arithmetic breaks 
> every kind of guarantee that would have with pointers, but aside from 
> that it would seem to me that the compiler could help to enforce data 
> marked as non-GC to not be assigned GC heap allocations.  This wouldn't 
> be allowed for classes or class references, since they are always 
> pointing to GC data, but perhaps for pointers and structs.  It seems 
> like it would be a helpful feature, but maybe I'm way off base.

In order for that to work, we would first need a precise scanner, as the 
current scanner scans ALL values in a block to see if any point at any 
heap memory, regardless of whether it is truly a pointer or not.

Also, if a pointer points to something outside the heap, there is no 
scanning of that data, since the GC doesn't know about it. The cost of 
having a pointer that points to a non-GC memory location is small (not 
entirely trivial, but it's just a few comparisons). The only true 
benefit would be to avoid scanning the entire block. This means that 
along with precise scanning, you couldn't have any GC pointers in the block.

As with most things, we need to prove the benefit with profiling before 
spending any time thinking about how to implement, and certainly before 
adding any language/library features.

-Steve