as a programmer you know and you can even control it by designing the appropriate scope and moving between scopes

> You lose nothing when going out of scope with GC.

actually, you don't know

Yes, I can, e.g. by implementing deferred deallocation, which is a primitive GC form.

> actually, you don't know

I know because I’ve verified it.

> Yes, I can, e.g. by implementing deferred deallocation, which is a primitive GC form.

sounds more like a form of manual memory management

Manual management involves an explicit function call. Functions called by a destructor are considered automatic.

How does this relate?

What exactly don't you understand?

how this relates to garbage collectors

Because that is precisely the trade-off we're discussing.

With immediate reference-counted reclamation, dropping the last reference can put an arbitrarily large amount of destruction and deallocation work on the current thread. If you defer that reclamation to get it off the critical path, you have introduced a collector that reclaims unreachable objects later.

Whether that collector discovers garbage by tracing or receives zero-reference objects from reference counting is an implementation detail. In both cases, memory reclamation is automatic and deferred.

So the supposed distinction "with ARC I know when I pay the reclamation cost, with GC I don't" only holds if you're willing to pay an unbounded reclamation cost synchronously when the last reference is dropped.