On Mon, Feb 24, 2025 at 2:01 PM JOHN MORRISON via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 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.

Hold on a second. If performance is irrelevant, if allocating a
control block is a valid implementation, if you're not even actually
referencing a true `std::unique_ptr` but instead must use some other
type (it has to be a new type if it needs to reference a control
block)... then why would you implement it in an unsafe way?

What you describe has *all* of the underlying mechanisms needed to
make proper weak ownership, to make using this type across threads
safe. It wouldn't cause any more overhead than you already have. It
wouldn't create any problems in terms of usability.

What you're proposing is purely aesthetic: you don't want to think of
the holder of a ptr_to_unique as having some ownership relationship to
the original, so you don't think the API should acknowledge and
enforce that. And you're willing to make the type more fragile just to
do that.

I don't see the point in making the class more fragile. `shared_ptr`
could have not allowed itself to be shared among threads; just remove
the atomic reference counting. But the cost of doing so was low, and
the benefits were high. And the same is true here: the cost is low,
and the benefits are high.