On 16/07/2020 21.34, Jefferson Carpenter via Std-Proposals wrote:
> On 7/16/2020 11:06 PM, Manuel Bergler via Std-Proposals wrote:
>> If `func` doesn't take ownership, why does it take a `ptr<T>` instead
>> of a `T*`? Can you give an example where using `ptr<T>` as an argument
>> to a function that doesn't take ownership is preferable to using `T*`?
>> I guess that would make it clearer what you're trying to accomplish.
>
> `func` takes a ptr because it is to take ownership if possible! Taking
> a `ptr<T>` instead of a `T*` indicates that the function /can/ take
> ownership.

I think I understand what you're trying to accomplish here.

IIUC, you want what is essentially a non-thread-safe reference-counted
pointer that allows a caller to transfer ownership to the callee, such
that the callee can free the object when it is no longer needed.

As I understand, you aren't *actually* reference-counting, although that
seems like a dangerous and unnecessary optimization, whereas the mental
model would be much simplified if we think of the pointer as being
reference-counted. I think I've deduced the critical features of your
pointer type in the previous paragraph.

That said... the trade-offs of a non-thread-safe reference counter
pointer are obvious. What I'm *not* seeing is a significant value in
being able to release the object in the callee, rather than when the
callee returns. This seems like a questionable improvement for the added
complexity.

Anyway, it seems that you could accomplish the same thing with a
non-thread-safe shared_ptr, and your proposal would be much easier to
understand if you simply presented it as such.

-- 
Matthew