Lol. I am not a proponent of Rust, I have never written a single line
of code in that language, nor did I read any book about it.

If you think I am wrong, then please show me how this mentioned issue
can be solved without a language level construct?

Also there is a problem of teachability, which I'm sure you are aware
of if you teached anyone about move-semantics:
- std::move does nothing,
- STD provides some guarantees about moved-from variables,
- better not to use moved-from variable except maybe for assigning it
a new value,
- std::move(x) will compile even if x is const.
- ...
It is just not a simple topic, and a language level move/relocate
would eliminate most of the complexity.

Regards,
Maciej

śr., 2 mar 2022 o 12:20 Ville Voutilainen
<ville.voutilainen_at_[hidden]> napisał(a):
>
> On Wed, 2 Mar 2022 at 13:15, Maciej Cencora <m.cencora_at_[hidden]> 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.
>
> Yay, more lofty declarations how relocation is the _only way_ to solve
> this problem. If I need
> relocation to solve this problem, I have a much bigger problem, where
> code I call doesn't do what
> it advertises to do in its interfaces, and relocation is not going to
> solve a problem as significant
> as that on that level. It's a performance tool, but I guess you're
> suggesting that it should be a correctness
> tool as well. Just out of curiosity, is that borrowing a page from the
> book of Rust?
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals