In other words - move means "I'm done with this, you can decide what
happens to it" and copy means "I'm not done with this, so no matter what
you do, its lifetime will last at least as long as my reference to it".

On 7/17/2020 1:34 AM, Jefferson Carpenter wrote:
> On 7/16/2020 11:06 PM, Manuel Bergler via Std-Proposals wrote:
>> Am Fr., 17. Juli 2020 um 00:32 Uhr schrieb Jefferson Carpenter via
>> Std-Proposals <std-proposals_at_[hidden]>:
>>>
>>> I see what you mean. The key difference is that std::unique_ptr and
>>> std::shared_ptr /always/ manage ownership (implicitly or by refcount).
>>> On the other hand, ptr ought to be usable in cases where you want to
>>> call functions whose argument type is ptr<T>, but you do not want the
>>> ptr to take ownership. For instance, you might have a T* that you've
>>> allocated separately and want to pass to a function taking a ptr. Or
>>> you might happen to have a stack-allocated value that you want to pass.
>>>
>>> Foo f;
>>> func(ptr(&f)); // subject to change
>>>
>>> The most natural thing for a ptr to do is to not have ownership.
>>
>> 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.
>>
>> Best
>> Manuel
>>
>
> `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.
>
> Compare the previous example with
>
> func(make_ptr<Foo>());
>
> Here, func actually takes an owning pointer. In this case, as soon as
> the ptr is nulled out somewhere in the execution of func, the instance
> of Foo is deleted. This excludes being nulled out due to std::move - in
> that case ownership is handed off again.
>
> Thanks for the questions, when I revise the original markdown file I'll
> try to be more clear about the precise semantics and intent.
>
> If anybody wants to help, I'd be more than happy to work together on an
> implementation and a more fleshed out proposal. :)
>
> Best,
> Jefferson