What is shared_ptr about it is the reference counted control block.   It does have weak_ptr in so far that you have pointers to the control block, but not insofar as they cannot be promoted (and they also cannot lock something in a different way).   The difference between your weak_ptr (ptr_to_unique) and your shared_ptr (notifying_unique_ptr) is at construction and destruction time and the ability to copy, which only your shared_ptr (notifying_unique_ptr) has.     I am just thinking, whether the implicitly contained unique_ptr in your solution should/could be made explicit (e.g. as template argument) instead.   -----Ursprüngliche Nachricht----- Von:JOHN MORRISON via Std-Proposals <std-proposals_at_[hidden]> Gesendet:So 16.02.2025 18:14 Betreff:Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership An:std-proposals_at_[hidden]; CC:JOHN MORRISON <inglesflamenco_at_[hidden]>; * Sebastian wrote - So it is basically a  single_thread_shared_ptr_without_weak_ptr_functionality<unique_ptr<T>>   I'm not sure how to unravel your single_thread_shared_ptr_without_weak_ptr_functionality concept but it doesn't sound right. There is nothing shared_ptr about it. It is designed to thoroughly respect single ownership. It does have the weak_ptr functionality of being non-owning and testable but not the ability to acquire ownership to keep something alive that is exposed to another thread. But that is ok because we never expose singly owned items to other threads (we already know that is an un-mitigateable disaster ) and that is all it can reference.   -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals