I think you've got it exactly backwards. By the time you've dealt with some of the various complexities manual memory management, for example: - handling mem

I think you've got it exactly backwards. By the time you've dealt with some of the various complexities manual memory management, for example: - handling memory with a dynamic lifetime (with cycle detection as an important corner case) - improving allocation performance - preventing heap fragmentation - thread-local allocators (for multi-threaded scalability) ... I think you're approaching a garbage collector. In fact, I'd even go so far as to say there is a memory-management analog for Greenspun's tenth rule: Any sufficiently complicated, long-lived program that manually manages memory contains an ad hoc, informally-specified, bug-ridden, slow implementation of a garbage collector. I agree there's a place for some amount of "hinting" to the garbage collector about the lifetime of some special objects, but, to me, the important thing is that you only need it for the extreme cases.