On 2022-03-02 at 12:15, Maciej Cencora via Std-Proposals wrote:
> You may assume whatever you want, but behaviour of your program may
> change depending on consume impl (because managed resource will be
> destroyed at different times).
> And without language level move/relocate, the only way to workaround
> this problem is to x = {}, after the consume call - but that requires
> default constructiblity which may not be possible/may be costly.

The only way?!

What about letting x go out of scope? That's what I usually do when I
don't need an object any more.




>
> śr., 2 mar 2022 o 12:08 Ville Voutilainen
> <ville.voutilainen_at_[hidden]> napisał(a):
>>
>> On Wed, 2 Mar 2022 at 12:56, Maciej Cencora via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>>> What is even worse, given following code:
>>> void consume(X&&);
>>> void bar()
>>> {
>>> X x;
>>> consume(std::move(x));
>>> ...
>>> }
>>>
>>> after the consume call, you have no idea whether x was actually
>>> consumed by invoking move-constructor/move assignment operator or not,
>>> without looking at the implementation of consume func.
>>
>> So what? I will just assume that it consumed x, and program
>> accordingly. I don't need to know that
>> it perhaps didn't.
>>
>>>
>>> The only way to solve this, is to introduce actual move/relocation as
>>> language level construct (via e.g. proposed relocate operator), i.e.:
>>> void consume(X x);
>>> void bar()
>>> {
>>> X x;
>>> consume(relocate x);
>>> ...
>>> }
>>> Now after the consume call, x is no longer 'accessible' for further
>>> code, and the user can be sure that the consume function really
>>> 'consumed' it.
>>
>> I'm sure there are valid and reasonable uses (performance) for
>> relocation, but this doesn't seem to be one of them.