Date: Mon, 24 Feb 2025 16:24:40 +0000
Hi Jason,
You wrote: Weak ownership in general is not that niche. What makes your
suggestion niche is the need to have weak ownership over a unique_ptr
*specifically*.
Absolutely, we already have weak_ptr for non-owning references to shared_ptr. The proposed ptr_to_unique is a non-owning reference to unique_ptr. It is all about serving single ownership which is often a requirement for important reasons.
You wrote: And I often find "safe with caveats" to be more dangerous than
"dangerous". In the latter case, everyone at least knows it's
dangerous and takes care, while the former case looks (and behaves)
fine... until it doesn't.
That is exactly the concerning issue with ptr_to_unique. Probably the only one.
You wrote: Also, the specific circumstance you cite ("GUI programming where all events are run in sequence by one thread") is exactly the kind of
circumstance where that sort of thing can *change*. GUI programming
needs to be responsive above all else, so if a response to a GUI event
needs to take some time, tossing it out to a separate thread is a
pretty common thing.
That is absolutely true anything that will take too long to complete will be tossed out to a separate thread but 'tossed out' is a correct expression of how we do it. It is tossed out of the GUI thread (unique_ptr swap) into one that will do the work, not to be seen again until the work is complete – an event is posted on the message queue to indicate completion, so that arrives in the GUI thread. We will try to avoid the GUI thread working on something that can also be worked on by another thread. Even with shared ownership it will require locks to prevent read/write clashes. We don't really want to go there. It is a lot of trouble and it isn't good to have locks in the GUI thread. With single ownership you have no choice. Simultaneous visibility of a singly owned object by multiple threads can never be threadsafe except by using seriously invasive locking of deletes as has been discussed.
I can't see this changing in the foreseeable future. The domain of use cases for ptr_to_unique is not going away.
________________________________
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> on behalf of Jason McKesson via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, February 24, 2025 4:16 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Jason McKesson <jmckesson_at_[hidden]>
Subject: Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership
On Sun, Feb 23, 2025 at 4:58 PM JOHN MORRISON via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hi Jason,
>
> I sorry if I give the impression that I am refusing to reply to specific e-mails. it just takes time to digest what is being said and get round to it. There have been many tangents in the discussion and it is a challenge to engage with them all at once. I have also been spending time revising the design to see if I can address some of the concerns. In some cases it might appear that I am replying to myself when I follow with a post that corrects something I have previously said. My long post was an attempt to address some concern collectively, draw together some coherence from the conversation so far (from my point of view) and clarify design aims that the conversation seems to have broadened beyond what I intended.
>
> The preamble has relevance. You say that C++ has *always* been in tension between safety and utility. That is true but due to the US government saying that the safety hasn't been good enough, there is a new imperative to pull harder on the safety side. I don't see it as a fangled paradigm. It is overdue. But it is new and I think we are all a bit unsure of where the balance should now lie. I see ptr_to_unique as being on the cusp of this because it is possible to write unsafe code with it in a multithread environment and it might even encourage you think it it is ok. You shouldn't because it has nothing to do with what it is for, but you can. I'm not sure how much of an obligation a feature has to prevent its incorrect use neither before nor now where the criteria may have shifted. Most of the discussion has been about exactly that. There have been outright rejections because it simply isn't threadsafe, helpful suggestion of how to make it threadsafe and a suggestion that it may not matter.
>
> I have been reeling back and forth figuring out where it should go in the light of all this.
>
> My feeling is that I am delighted with it. It fits my needs perfectly but I am slightly nervous that others might get the wrong idea of what it is for and that there is nothing to stop them. That is why I came up with another tangent which is to throw an exception if an unsafe dereference is attempted. I have introduced it, pulled it back out and haven't ruled out putting it back in.
>
> I want to address some of the things you have said:
>
> I have to take issue with your idea that ptr_to_unique is shared ownership in some way. It isn't. It has no control of ownership whatsoever (that is why it can't be threadsafe in the same way as weak_ptr). It remains valid while in use simply because you have tested it and no other thread will intervene and delete it before you can use it.
It is *de-facto* shared ownership. There is no API proclaiming it to
be shared, but if two pieces of code have some place where they
require the same object to still exist, then they are sharing
ownership of that object. When the user of a `ptr_to_unique` checks
for a pointer, finds it valid, and uses it, that action claims
ownership over the object.
The API may not *enforce* that claim, but it is there nevertheless.
> You wrote: The main issue I have with this type is that its reference mechanics
> are unsafe in a different way from other reference types.
>
> I am not sure what you mean by this. I can't see anyway in which it is less safe than a raw pointer or a C++ reference.
The subsequent paragraphs after that statement explain the issue.
The short version is that there's no "right way" to check to see if a
raw pointer has been deleted; you cannot ask that question of one. Raw
pointers are always dangerous; weak_ptr is always safe.
`ptr_to_unique` is safe... with caveats.
And I often find "safe with caveats" to be more dangerous than
"dangerous". In the latter case, everyone at least knows it's
dangerous and takes care, while the former case looks (and behaves)
fine... until it doesn't.
> You wrote: So what we have in this `ptr_to_unique` is a type with extremely niche
> functionality (ie: most people won't be familiar with it) coupled with
> being brittle in a way that is unique in the C++ standard library.
>
> That its use case is extremely niche and most people won't be familiar with it has come as a big shock for me. I am not saying you are wrong, it's just that I spent several decades working in that niche. It hadn't really occurred to me that others would be so unfamiliar with it. Obviously anyone unfamiliar with that niche is not going to see it utility. That means that it is not going to fare well in utility versus risk equation in most peoples eyes. For that reason alone I don't think I should get my hopes up too much. It has been very helpful for you to say this.
>
> I am not sure that it is brittle in a way that is unique in the C++ standard library but that isn't going to matter if it isn't perceived as being useful.
>
> Probably the most difficult task facing me is getting across that this niche does exist, it is quite big (GUI programming where all events are run in sequence by one thread) and it is a place where accidents happen because we don't have the safety of persistent secondary references to uniquely held objects properly covered. We need them, we use them and we can get into trouble managing them.
Weak ownership in general is not that niche. What makes your
suggestion niche is the need to have weak ownership over a unique_ptr
*specifically*.
After all, you could just have a `shared_ptr` that you only "share"
via `weak_ptr`s. There wouldn't be any API guardrails preventing you
from sharing ownership unintentionally. But it would solve your
problem.
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.
Also, the specific circumstance you cite ("GUI programming where all
events are run in sequence by one thread") is exactly the kind of
circumstance where that sort of thing can *change*. GUI programming
needs to be responsive above all else, so if a response to a GUI event
needs to take some time, tossing it out to a separate thread is a
pretty common thing.
So it seems to me that this area of code would be particularly prone
to such issues.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]pp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
You wrote: Weak ownership in general is not that niche. What makes your
suggestion niche is the need to have weak ownership over a unique_ptr
*specifically*.
Absolutely, we already have weak_ptr for non-owning references to shared_ptr. The proposed ptr_to_unique is a non-owning reference to unique_ptr. It is all about serving single ownership which is often a requirement for important reasons.
You wrote: And I often find "safe with caveats" to be more dangerous than
"dangerous". In the latter case, everyone at least knows it's
dangerous and takes care, while the former case looks (and behaves)
fine... until it doesn't.
That is exactly the concerning issue with ptr_to_unique. Probably the only one.
You wrote: Also, the specific circumstance you cite ("GUI programming where all events are run in sequence by one thread") is exactly the kind of
circumstance where that sort of thing can *change*. GUI programming
needs to be responsive above all else, so if a response to a GUI event
needs to take some time, tossing it out to a separate thread is a
pretty common thing.
That is absolutely true anything that will take too long to complete will be tossed out to a separate thread but 'tossed out' is a correct expression of how we do it. It is tossed out of the GUI thread (unique_ptr swap) into one that will do the work, not to be seen again until the work is complete – an event is posted on the message queue to indicate completion, so that arrives in the GUI thread. We will try to avoid the GUI thread working on something that can also be worked on by another thread. Even with shared ownership it will require locks to prevent read/write clashes. We don't really want to go there. It is a lot of trouble and it isn't good to have locks in the GUI thread. With single ownership you have no choice. Simultaneous visibility of a singly owned object by multiple threads can never be threadsafe except by using seriously invasive locking of deletes as has been discussed.
I can't see this changing in the foreseeable future. The domain of use cases for ptr_to_unique is not going away.
________________________________
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> on behalf of Jason McKesson via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, February 24, 2025 4:16 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Jason McKesson <jmckesson_at_[hidden]>
Subject: Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership
On Sun, Feb 23, 2025 at 4:58 PM JOHN MORRISON via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hi Jason,
>
> I sorry if I give the impression that I am refusing to reply to specific e-mails. it just takes time to digest what is being said and get round to it. There have been many tangents in the discussion and it is a challenge to engage with them all at once. I have also been spending time revising the design to see if I can address some of the concerns. In some cases it might appear that I am replying to myself when I follow with a post that corrects something I have previously said. My long post was an attempt to address some concern collectively, draw together some coherence from the conversation so far (from my point of view) and clarify design aims that the conversation seems to have broadened beyond what I intended.
>
> The preamble has relevance. You say that C++ has *always* been in tension between safety and utility. That is true but due to the US government saying that the safety hasn't been good enough, there is a new imperative to pull harder on the safety side. I don't see it as a fangled paradigm. It is overdue. But it is new and I think we are all a bit unsure of where the balance should now lie. I see ptr_to_unique as being on the cusp of this because it is possible to write unsafe code with it in a multithread environment and it might even encourage you think it it is ok. You shouldn't because it has nothing to do with what it is for, but you can. I'm not sure how much of an obligation a feature has to prevent its incorrect use neither before nor now where the criteria may have shifted. Most of the discussion has been about exactly that. There have been outright rejections because it simply isn't threadsafe, helpful suggestion of how to make it threadsafe and a suggestion that it may not matter.
>
> I have been reeling back and forth figuring out where it should go in the light of all this.
>
> My feeling is that I am delighted with it. It fits my needs perfectly but I am slightly nervous that others might get the wrong idea of what it is for and that there is nothing to stop them. That is why I came up with another tangent which is to throw an exception if an unsafe dereference is attempted. I have introduced it, pulled it back out and haven't ruled out putting it back in.
>
> I want to address some of the things you have said:
>
> I have to take issue with your idea that ptr_to_unique is shared ownership in some way. It isn't. It has no control of ownership whatsoever (that is why it can't be threadsafe in the same way as weak_ptr). It remains valid while in use simply because you have tested it and no other thread will intervene and delete it before you can use it.
It is *de-facto* shared ownership. There is no API proclaiming it to
be shared, but if two pieces of code have some place where they
require the same object to still exist, then they are sharing
ownership of that object. When the user of a `ptr_to_unique` checks
for a pointer, finds it valid, and uses it, that action claims
ownership over the object.
The API may not *enforce* that claim, but it is there nevertheless.
> You wrote: The main issue I have with this type is that its reference mechanics
> are unsafe in a different way from other reference types.
>
> I am not sure what you mean by this. I can't see anyway in which it is less safe than a raw pointer or a C++ reference.
The subsequent paragraphs after that statement explain the issue.
The short version is that there's no "right way" to check to see if a
raw pointer has been deleted; you cannot ask that question of one. Raw
pointers are always dangerous; weak_ptr is always safe.
`ptr_to_unique` is safe... with caveats.
And I often find "safe with caveats" to be more dangerous than
"dangerous". In the latter case, everyone at least knows it's
dangerous and takes care, while the former case looks (and behaves)
fine... until it doesn't.
> You wrote: So what we have in this `ptr_to_unique` is a type with extremely niche
> functionality (ie: most people won't be familiar with it) coupled with
> being brittle in a way that is unique in the C++ standard library.
>
> That its use case is extremely niche and most people won't be familiar with it has come as a big shock for me. I am not saying you are wrong, it's just that I spent several decades working in that niche. It hadn't really occurred to me that others would be so unfamiliar with it. Obviously anyone unfamiliar with that niche is not going to see it utility. That means that it is not going to fare well in utility versus risk equation in most peoples eyes. For that reason alone I don't think I should get my hopes up too much. It has been very helpful for you to say this.
>
> I am not sure that it is brittle in a way that is unique in the C++ standard library but that isn't going to matter if it isn't perceived as being useful.
>
> Probably the most difficult task facing me is getting across that this niche does exist, it is quite big (GUI programming where all events are run in sequence by one thread) and it is a place where accidents happen because we don't have the safety of persistent secondary references to uniquely held objects properly covered. We need them, we use them and we can get into trouble managing them.
Weak ownership in general is not that niche. What makes your
suggestion niche is the need to have weak ownership over a unique_ptr
*specifically*.
After all, you could just have a `shared_ptr` that you only "share"
via `weak_ptr`s. There wouldn't be any API guardrails preventing you
from sharing ownership unintentionally. But it would solve your
problem.
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.
Also, the specific circumstance you cite ("GUI programming where all
events are run in sequence by one thread") is exactly the kind of
circumstance where that sort of thing can *change*. GUI programming
needs to be responsive above all else, so if a response to a GUI event
needs to take some time, tossing it out to a separate thread is a
pretty common thing.
So it seems to me that this area of code would be particularly prone
to such issues.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]pp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-02-24 16:24:45