I think the criticism here is a bit too far, regarding threads.
If you are ever in the situation where you can check if the pointer is
alive and the unique_ptr deletes the data in another thread, you already
have a data-race.
We have iterator to all standard containers, but no one would propose them
to be thread safe. They all have the same problem: they become invalid if
you clear the container in another thread, or interrupt, or even in other
function calls.
It's just an inherent characteristic of the design.
It doesn't make it useless, just need to be careful when using it, much
like iterators.

I don't know if the proposal is standard material, but I also disagree on
the nitpicking about thread-safety.

I can even see how this can be applied in my compiler.
I may have a list of objects to optimize: A B C
But in optimizing A, it could be that B and C also get optimized and
deleted.
If I had the feature being proposed here, I could make my initial list of
these pointers, and before optimizing each element, I check if they are
still there.

My suggestion is for you to document more real-world use cases and show
your feature could have been used there.

Em seg., 24 de fev. de 2025, 16:01, JOHN MORRISON via Std-Proposals <
std-proposals_at_[hidden]> escreveu:

> ptr_to_unique does use a control block. It isn't as burdensome as that of
> shared_ptr/weak_ptr but it is more than half way there. It also requires
> the unique_ptr it works with to be fattened by a notifying mechanism
> (custom deleter) that holds a pointer to the control block.
>
> Performance isn't the motivation. The motivation is to have something that
> works with unique_ptr because single ownership is often a requirement in a
> model and I want to hold long term references to items within that model
> that test as null when they are no longer valid.
>
> ------------------------------
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf
> of Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]>
> *Sent:* Monday, February 24, 2025 7:39 PM
> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Cc:* Thiago Macieira <thiago_at_[hidden]>
> *Subject:* Re: [std-proposals] A non-owning but self zeroing smart
> pointer for single ownership
>
> On Monday, 24 February 2025 12:16:16 Brasilia Standard Time Jason McKesson
> via
> Std-Proposals wrote:
> > As such, the non-aesthetic reason to specifically create a
> > `ptr_to_unique` instead of just using `shared/weak_ptr` is
> > performance: the latter involves book-keeping that (presumably) a
> > `ptr_to_unique` implementation could avoid.
>
> It can't.
>
> If you remove the book-keeping, then ptr_to_unique really *is* a pointer to
> std::unique_ptr. We don't need a new class for that; just use the pointer
> and
> make sure the std::unique_ptr itself doesn't get destroyed or replaced
> while
> something is pointing to it.
>
> If you want to be able to have the ptr_to_unique be able to survive the
> destruction or replacement of the unique_ptr they referred to, you need the
> ref-counted block containing something that says the pointed object is
> still
> alive. And THAT is what shared_ptr + weak_ptr do.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>