GC pragma on ref type: does disabling GC propagate to referenced objects?

The short answer: no. Applying {.gc: "none".} to a ref type suppresses GC tracking of the reference itself — the pointer — not of the object it points to. The pragma does not propagate. If you want the pointee to be untracked as well, you must annotate the pointee type explicitly. The details below explain why, and where the behavior diverges between backends.

What the pragma actually does

The gc pragma is attached to a type, and in Nim a ref T and its pointee T are distinct types. Marking the ref type tells the compiler to treat that reference more like a raw pointer: it is excluded from the collector's root/scanning bookkeeping for that type. The pointee's own type definition still governs whether the collector traces it. So a ref object marked {.gc: "none".} pointing at an ordinary object leaves that object fully scannable — exactly the retention surprise described in the question.

Backend differences (likely explanation)

The mechanism differs by memory-management backend, and this is where version assumptions matter:

• Boehm (conservative GC, traditional Nim 1.x default): the collector scans memory for pointer-like words. An untracked reference means the collector may not discover the path to the pointee through that reference, but the pointee's allocation is still a GC-managed block and remains scannable/reachable via any other tracked path.
• ARC/ORC (default in Nim 2.x): management is deterministic reference counting inserted at compile time. The pragma changes whether the compiler emits incref/decref operations for that type. Again, this is per-type: the pointee's operations are governed by its own annotation.

Because the pragma is experimental and the default backend changed between Nim 1.x and 2.x, treat any cross-version claim as provisional and verify on your exact compiler version.

Practical guidance

1. Annotate the pointee type with {.gc: "none".} if you want complete suppression; annotating only the ref is insufficient.
2. Once a type is untracked, you own its lifetime: allocate and free manually (or use a scoped pattern), otherwise you leak.
3. Beware the dangling-pointer trap: if the only remaining reference to a GC-tracked pointee is an untracked ref, the collector may reclaim the object while your raw reference still points at it.

How to verify on your setup

Since behavior here is version- and backend-sensitive, confirm empirically rather than trusting documentation:

# Compile with each backend and inspect generated C for GC registration calls
nim c --gc:boehm -d:danger yourtest.nim
nim c --mm:arc  -d:danger yourtest.nim

Compare the generated C for a plain ref versus the annotated ref: the absence of GC registration/scanning calls for the annotated type confirms the pointer-level suppression. A small allocation loop plus a forced collection can then show whether the pointee is still traced. If your decision hinges on exact Nim 2.x semantics, include your compiler version (nim --version) when seeking confirmation — that single detail determines which answer applies.