You would usually do it for performance rather than RAII correctness. For example, without GC, your library might use RAII with std::shared_ptr, for certain ob

You would usually do it for performance rather than RAII correctness. For example, without GC, your library might use RAII with std::shared_ptr, for certain objects that outlive lexical scope. That is, reference counts tied to pointer copies and destructors. With GC, your library might omit the reference counts when deferred object destruction is ok, saving a little space and time. If your library is dealing with something like a graph (nodes connected by pointers) which may have cycles, std::shared_ptr will not be enough to free all objects as they become unused, but the environment GC will do it. Therefore, without an environment GC, your graph-using library will need its own cycle detector, or if usage permits, something with arenas or std::weak_ptr. With GC, your graph-using library can omit that code entirely. There are occasions when you'd want to add code for correctness when using a GC, to release objects by clearing pointers to them in some circumstances where it's safe to leave the pointer uncleared (and possibly invalid but harmless) without GC.