As has been pointed out, this model doesn't work unless you're willing to make it undefined behaviour to access your smart pointer without providing sufficient synchronization to ensure that the access happens-before the destruction of the source unique_ptr.

weak_ptr gets around this by not being dereferencable unless you convert it to a shared_ptr by using lock() and therefore guaranteeing that the object can't be destroyed while you're using it unless you go out of your way to extract the raw pointer from the shared_ptr and letting the shared_ptr destruct.

unique_ptr has no such mechanism for ensuring that holding a reference maintains the lifetime of the owned object, so in order for your smart pointer to be usable you either need to prove that the unique_ptr won't be destroyed while you're holding it (in which case you don't need a smart pointer, a regular pointer would do) or you need to add some extra mechanism to your unique_ptr to allow you to temporarily upgrade the fancy pointer type to a special version that prevents the unique_ptr from destroying the object (at which point you're just reinventing shared_ptr).

Basically, this proposal seems like it has the choice of either adding a huge surface for undefined behaviour and hence bugs (by effectively disallowing multithreaded use except in trivial cases) or evolving to become shared_ptr. Neither option seems particularly attractive as something to add to the standard.


On 13 February 2025 19:37:49 GMT, JOHN MORRISON via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
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.