In a multithreaded variant it would not be enough to check the pointer, as its state can change directly after the check before the access. That is the reason weak_ptr promotes to shared_ptr during an access.   In single-threaded programs you can know whether you call any function that may indirectly change the state or may relinquish control to callbacks or interrupts, calling in turn routines, which may change the state.   -----Ursprüngliche Nachricht----- Von:Simon Schröder via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Sa 22.02.2025 08:59 Betreff:Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership An:std-proposals_at_[hidden]; CC:Simon Schröder <dr.simon.schroeder_at_[hidden]>;    On Feb 20, 2025, at 10:49 PM, JOHN MORRISON via Std-Proposals <std-proposals_at_[hidden]> wrote:  Ok, there is a real thread safety issue, it is serious and I have been working on it.  I think you have some interesting thoughts here. Maybe ptr_to_unique could get a template parameter that defaults to multithreaded use (which will have additional memory overhead), but with an explicit template parameter it can be made single threaded (for memory efficiency and performance reasons). Since the template parameter would be explicit it reduces wrong usage.  I am not sure if throwing an exception when accessing ptr_to_unique is the right choice. Since you should check if the pointer is nullptr before using it ptr_to_unique could always return a nullptr/check equal to nullptr in other threads. No throwing necessary. However, any sort of check for the current thread slows down ALL access to the pointer—even legitimate access. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals