> On Feb 17, 2025, at 6:26 PM, JOHN MORRISON via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> My need for this arose in the development of event driven GUI applications which are a form of cooperative multitasking all running in one thread. A lot of lifetimes can come and go but all the event handlers that you write are running in the same thread. Typically I will be displaying a polymorphic collection of objects and may run a procedure to pick out some that require special attention. I don't want to run that procedure every time the screen is repainted so I hold pointers to those objects. If the pointer is still valid, I use it. If not then its do nothing or run the procedure again. It was a necessary optimisation to prevent screen lag and I used to write a lot of very intrusive and fragile spaghetti code to make sure that those pointers were zeroed if their pointee was deleted.
>
I guess this use case would be the motivating example for your proposal. I just recently learned that Qt has QPointer which does exactly this. I have never used it because I didn’t know about its zeroing capabilities.

So far, we have established that it should only be used within a single thread (and a second proposal could suggest a thread safe alternative based on shared_ptr/weak_ptr making it unique instead of shared). In that case it does not make sense having a stack variable (i.e. a variable in local function scope) as ptr_to_unique. Your motivating example should not show this. The only use case for this type (as I see it) is to use ptr_to_unique as member variable. This is the only use case where in a single threaded context (or multi threaded, but the other threads don’t have anything to do with this unique_ptr) the pointer can be zeroed out while the ptr_to_unique still exists. (Other use cases could be global or static variables. I’m not sure these are the correct motivation.)
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals