1. Calling dispose method when the rcgc_shared_ptr is destroyed is still wrong. By definition, there are supposed to be multiple pointers to a shared object, and destroying a single shared pointer must not result in "cleaning up" the shared object. -- So disposing here is not meaning “cleaning up“ but “trying to clean up”(it’s better to have another word to call it), !A() serves as ~A() the difference is it just call the disposing methods of the field’s members’ rcgc_shared_ptrs to decrease reference counts. Actually they can be almost same (!A() and ~A()) in generated assembly or machine code. Only difference is !A() only calls about the rcgc_shared_ptr, and ~A() calls about all the dtors of field members. Yes, this is upon the assumption that the memory of that object is not touched or messed up (since not ~A(), just !A(), then it should not be touched by design). 2. What is the purpose of the special syntax of the dispose function? What is its semantics outside the rcgc_shared_ptr? Why do you need this special syntax and not a regular method that is used by rcgc_shared_ptr? These are the sort of questions you will be asked by the committee when you bring this proposal. In fact, I think you'll me asked these even before you bring the proposal before the committee. There needs to be a very strong reason to introduce a new syntax. -- The purpose is only to answer Rob’s reply: if trying to make things look beautiful without changing the original design of C++ language, the only choice is to add some extra syntax. Yes, this needs a very strong reason. So what do you think, if reference counting algorithm can be tuned up into “universal” mode and achieve the goal that the smart pointers are designed to achieve? (the one and only smart pointer to manage memories without coders’ attention) The reply to Rob was not cc to the list and this reply is following that one. I already said in that one, it’s not my purpose to bring a proposal to the committee. Reason: things evolve, and the good ones continue and being accepted, and the users are the judges, so let the users judge. If good enough, got accepted; not good enough, got forgotten. So this would not be a problem. I think or hope you already read and debug the code and already be aware of how it works. This understanding of the code is the basic ground we talk about further. Because the code answered the reason already. (We’re coders, aren’t we? The code speaks better then my vocabulary-limited English.)