For the sake of market research, are you wanting this pointer because:

(1) You want to be sure you don't accidentally invoke pointer arithmetic?
  (1a) accidental *ptr++ when you meant (*ptr)++
  (1b) accidental ptr += when you meant (*ptr) +=
(2) You want to block yourself from accidentally assigning to the pointer?
  (2a) accidental ptr = 0 when you meant (*ptr) = 0
  (2b) accidental ptr = false when you meant (*ptr) = false
(3) You'd like to use reset() and get() on the pointer, for purposes of
generic code?
(4) You'd like to pass a shared_ptr or unique_ptr or raw pointer to a
routine, without having to worry about whether you need to call get() or
not.
  (4a) current workaround is to pass &*ptr to the function...
(5) You prefer a coding style where you never have raw pointers?

= - = - = - =

Me personally, I think there's a very large body of code where a given
pointer has a unique owner, a fairly-well-defined lifetime, and then a
bunch of code that uses the data pointed to by that pointer. Furthermore,
these situations occur often with data that isn't heap allocated, that is,
a stack object or an object that is encapsulated in some bigger object.

But we all know that shared_ptr is expensive, especially in a
multi-threaded context, because of reference counting and mutex acquisition
etc.

So I guess what I'm saying is, I want to be able to have just the
"weak_ptr"-like functionality of shared_ptr... and to be able to attach it
to any class... either:
(A) just like weak_ptr for shared_ptr, with all the weak_ptr objects being
protected by atomic operations so that if the object is deleted in one
thread, it can be detected in the other,
OR
(b) except that any attempt to use a weak_ptr when its pointer has gone
would check-fail. For bonus points, it should be ifdef'd in such a way
that I can turn it all into straight pointer semantics once I'm convinced
all the lifetime issues have been taken care of.

std::allocate_shared, called with a do-nothing allocator, is nearly perfect
for this use case.

= - = - = - =

This is the bane of experience: A new C++ programmer can implement
non_owned_ptr in a day. An experienced programmer sees the plurality of
options, and comes back after a week with questions rather than code.

-- Jorg


On Sun, Nov 10, 2019 at 7:45 PM Steve Weinrich via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I was thinking that a non_owned_ptr would be a good std addition. The idea
> is to formalize the current convention of using raw pointers to represent
> transient pointers (transient_ptr might be a better name).
>
> Aside from a lot of details, it would simply be a template wrapper around
> a raw pointer. On destruction, the wrapper would do nothing.
>
> This would allow the enforcement of the intended behavior.
>
> What do you all think?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>