C++ has and will have both: Safe tools and performant tools.   John, you should be clear as OP, what this proposal is about.    - Performance and zero overhead? (Compared to shared_ptr)  - Safety? (Compared to unique_ptr)  - Better representation of single ownership/multiple pointers? (More about interface?)  - Graceful error handling? (vs. UB vs. termination/dead-lock)   If it is NOT about performance, it should be safer, more like a shared_ptr with single ownership.   If it is about performance, use something like  - the separately allocated control block with reference counters, or  - the doubly linked lists, or - not discussed yet -  - some global object registry, which stores an object id at a memory location, if the object is alive; the entry can be reused for other objects.     The comment that it is not meant for better performance than shared_ptr, was confusing, as so far that is the main reason to give it a different implementation than shared_ptr or shared_ptr with different interface for single owner.   -----Ursprüngliche Nachricht----- Von:Simon Schröder via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 25.02.2025 07:12 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 24, 2025, at 11:02 PM, JOHN MORRISON via Std-Proposals <std-proposals_at_[hidden]> wrote:  The motivation isn't better performance than shared_ptr but I don't want it substantially worse either. It is going to be used to optimize painting routines so they don't cause screen lag. I suspect that setting and testing locks may have more latency and there can be a lockout on the GUI thread if a lock get hit.  I can confirm that this is really important in GUI programming. If you are drawing a 1000 objects on screen, you cannot acquire a lock for each of them during painting. You’ll never get a responsive UI this way.  I guess the major discussion should be a meta-discussion. What do we prioritize in C++: * thread safety? * or the zero overhead principle (you don’t pay for what you don’t use)? Is the zero overhead principle not a major thing in C++ anymore? Does it not get trumped by the safety discussion? Is C++ not classical C++ anymore? (I don’t really know.)  This discussion about a general direction of C++ should inform the implementation of ptr_to_unique. As long as we hold to the zero overhead principle ptr_to_unique should not check if it is running in the correct thread (by default) and should definitely not use locking (by default). I already suggested to have a template parameter which can select between safety and performance. The question is then what should be the default. Should we opt out to get zero overhead? Or is zero overhead the default and we opt in to safety? Can we use profiles which change the default? -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals