There could be two reasons (beside being more explicit) not to use shared_ptr:  - performance (no thread synchronization needed)  - single ownership; deterministic destruction   The first point is the reason for a possible new class   For the second point (without the first) in multi-threaded environments, I have suggested the possibility (not necessarily for the standard library) to extend shared_ptr to do the destruction in two steps instead to get rid of race conditions and be able to handle the shared_ptr being locked:  - deactivate the promotion of weak_ptr to shared_ptr (promotion afterwards returns as if it is destructed already)  - safely and deterministically destruct the pointed to object     -----Ursprüngliche Nachricht----- Von:Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 17.02.2025 12:55 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]>;   conditions where you would use it but also couldn’t just use a shared_ptr.