> That is true but it is made safe by using shared ownership. I don't think you can safely use a pointer to a unique_ptr controlled by another thread. If there is a way, tell me, and I'll do that instead of throwing an exception.

The other way is user manages a lock (if it needs one) implementation details dependent on the use case.

If you are placing thread id controls on the weak_ptr then now the problem shifts back to how can you prevent the owning_ptr from switching ownership? Or is ownership forever tied to that one thread that created it?
Will my application just throw an exception (or crashes if I tried)?

Besides thread local storage, the concept of “thread ownership” of a variable is not really a thing.

The paper would be dead before it even started.

Throwing an exception is putting a band aid on an amputated hand.
If your top concern is safety, then I would rather advise you not to propose the feature.

No stl container is thread safe as far as I’m concerned, that doesn’t necessarily pose a security risk.

It’s one thing for a feature to have limitations that you can work with.
It’s a completely different thing for a feature to have contradicting design goals, in this case to attempt to achieve thread safety but still not really being thread safe.

We know this model cannot be thread safe.
Maybe the paper will get shot down due those safety concerns, maybe not.
But it will for sure be shot down because of contradictory design goals, or attempts to fix something that doesn’t actually fix anything.


From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of JOHN MORRISON via Std-Proposals
Sent: Friday, February 21, 2025 11:34 AM
To: std-proposals_at_[hidden]
Cc: JOHN MORRISON <inglesflamenco_at_[hidden]>
Subject: Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership

Re: Change to catch unsafe use with exceptions.

Tiago wrote: I wouldn't go further to extend it. There's nothing that says that creating a pointer in one thread and using in another cannot be made safe.

That is true but it is made safe by using shared ownership. I don't think you can safely use a pointer to a unique_ptr controlled by another thread. If there is a way, tell me, and I'll do that instead of throwing an exception.

Tiago also wrote: Sometimes it's just better to do nothing and be aware of the limitations. If you are going to put further constraints, it will also less likely to be useful.

I think the question is should you burden correct use with thread checks just in case somebody has a go at incorrect use. Traditionally the answer would be no. You are paying for something that you don't intend to use – classify the incorrect use as ill formed code and leave it at that. However now that there is an existential imperative to make C++ safer, a different view might prevail. A smart pointer will be expected to do clever things and all of it safely, so allowing it to do unsafe things under the illusion of it being safe probably should be prevented.

The change is only three lines of code although it was a bit of a head bender figuring out how that makes it work. A compromise between the traditional view and the more modern safety imperative might be to have those lines conditionally compile just for Debug builds.

I think there has to be something to prevent you from writing code that looks good, compiles without warnings and appears to work but will go off the rails at some indeterminate point in the future. That is exactly the sort of thing that gives C++ a bad reputation.