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.

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.

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.

Cheers, John,