On 7/18/2020 8:18 PM, Jason McKesson via Std-Proposals wrote:
>
> You may have missed a crucial part of the example. It was specifically
> about a function that *stores* the pointer in an object (perhaps the
> function is that object's constructor). The expectation in the
> `unique_ptr` case is that the object now owns that resource. The
> expectation in the `ptr` case is... what? Maybe the object owns it,
> maybe it doesn't? So how do you now test the behavior of the object
> after this function's execution?
>
> After all, the object stored that `ptr` so that it can use it. Which
> functions on that object are expected to be valid in the event of a
> dangling pointer and which aren't?
>
> If you're in the realm of pure functions with immutable state, maybe
> this type makes sense. But in the real world, where state is changed
> frequently and resources are owned by more than just stack variables,
> this just isn't tenable as a general-purpose tool.
>

Ah, I think you're asking what happens with aliasing. As a trivial
example that bypasses even object storage

     template<typename T>
     ptr<T> identity(ptr<T> t) {
         return t;
     }

     void foo() {
         ptr<T> x = /* something */;
         ptr<T> y = identity(x);
     }

y refers to the same object as x, so it is no longer clear which one has
ownership. This also comes up when an object has a ptr<T> member.

In that case, as written you just have to know what the functions you
call do with the pointers you pass in, in particular whether they alias
the pointers (which leads to their having preconditions on the lifetimes
of the ptr<T>'s they are passed).

If it's desirable not to have to know this, then it might be good to
have a non-thread-safe refcount. I'll think about the consequences of
this and try to work it into the next revision of the document.