What the OP probably wants, is a guarantee that no other shared_ptr to the object exist after a certain point.         As you say, it would be like a shared_ptr + weak_ptr.   shared_ptr (primary) + weak_ptr. The weak_ptr transforms into a shared_ptr (secondary), when accessing.     with the added property that     ==== First alternative ====   an exception would be thrown, if the primary shared_ptr is destructed and there are still secondary shared pointers out there.     This can be easily built and checked in a single threaded world:   if (shared.use_count > 1)     throw ... else     delete shared;   In a multi-threaded world one can neither put the check before nor after the delete, as any weak_ptr could be converted into another shared_ptr between check and delete (by another thread) or any other shared_ptr could be deleted between the delete and a check afterwards (by another thread).   The check would have to be built into the special shared_ptr itself.     ==== Second alternative ====   Or the OP wants a shared_ptr that blocks, when the primary shared_ptr is deleted, until no secondary shared_ptr exist anymore and the shared_ptr is really gone. Weak pointers can still exist.   So one could introduce some kind of blocking super delete into shared_ptr.   The danger is of course a deadlock.     ==== Third alternative ====   A function within shared_ptr, which deactivates the generation/promotion of other shared_ptr from weak_ptr.   So one could do:     shared.deactivatePromotion(); if (shared.useCount > 1)     ... // error handling, we are not alone; we can throw an error or wait and try and test useCount again else     shared.reset(); // the pointed to object definitely is destructed         -----Ursprüngliche Nachricht----- Von:Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 13.02.2025 21:24 Betreff:Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership An:std-proposals_at_[hidden]; CC:Tiago Freire <tmiguelf_at_[hidden]>; This is not a good proposal for 2 reasons.   1. You would need to make unique_ptr more complex in order to support the notification mechanism to the non-owning pointer. Which goes against the philosophy of not paying for what you don't use. And this would penalize current developers who use unique_ptr, and don't use this feature and don't want to pay for it.   But this problem can be mitigated by creating a new "complex_unique_ptr" type.     2. In a post multi-threaded world this is a bad idea that simply wouldn't work. You need to take in consideration code context, ownership and life times of objects. If the life time of the smart pointer is guaranteed in the current execution context you simply don't need an extra smart pointer, a reference to the original unique_ptr would do, or even a the actual raw pointer. If you can't guarantee the life time, because your new pointer is not an owning pointer, even if you validate before use, by the time you actually use the object could already have been deleted leading you to dereference a dangling pointer. This model doesn't work.   What you are looking for is a shared_ptr and a weak_ptr. A weak_ptr works because the process of validation is to acquire a shared_ptr in the current context, which guarantees that by the time you use the pointer is not dangling because you have a shared_ptr that prevents it from being destroyed.         -------------------------------- From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of JOHN MORRISON via Std-Proposals <std-proposals_at_[hidden]> Sent: Thursday, February 13, 2025 8:37:59 PM To: std-proposals_at_[hidden] <std-proposals_at_[hidden]> Cc: JOHN MORRISON <inglesflamenco_at_[hidden]> Subject: [std-proposals] A non-owning but self zeroing smart pointer for single ownership A non-owning but self zeroing smart pointer for single ownership We need this when we want hold a persistent reference to an object already owned by a unique_ptr to use later if it is still valid. Not having it leaves us using raw pointers and we don't have a good art of preventing them from dangling (knowing if they are still valid). Our mitigations tend to be fragile and often break. It is scary enough to deter us from doing such a thing but sometimes we have to and it is here that dangling pointers remain a huge hazard. It doesn't have to be like that, We can have a smart pointer for the role but it will be involve intrusion on the owning unique_ptr declaration so it can notify deletes and some reference counting overhead but with that it is rock solid (valid or null). Here is a working example: https://github.com/make-cpp-nice/ptr_to_unique A smart pointer to an object already owned by a unique_ptr. It doesn't own the object but it self zeroes when the object is deleted so that it can never dangle. The addition of something like this to the Standard Library would complete safe smart pointer coverage for heap allocated objects. It is the missing piece needed to do this. Its safe encapsulation of an idiom that was unreasonably hazardous will also open up new design opportunities.   -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals