śr., 2 mar 2022 o 12:38 Ville Voutilainen
<ville.voutilainen_at_[hidden]> napisał(a):
>
> On Wed, 2 Mar 2022 at 13:33, Maciej Cencora <m.cencora_at_[hidden]> wrote:
> >
> > 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.
>
> Right, I was just curious if perhaps rust-like semantics were what you
> were aiming for.
>
> > If you think I am wrong, then please show me how this mentioned issue
> > can be solved without a language level construct?
>
> Convention. Don't declare functions to take rvalue references if they
> don't move, or otherwise document
> such functions if they move only sometimes. That's what we do today,
> and I don't have much evidence
> of that being insurmountable.
Convention is not a solution, as it is optional, and it is not
automatically checkable.

>
> > 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,
>
> It does what it claims to do, it enables moving.
I don't see it being named 'std::enable_move', so it doesn't do what
it's name claims to do!

>
> > - 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.
>
> ..while introducing fair amounts of different complexity.
Assuming we chose 'move' as a contextual keyword for such an
operation, a code like this :
X sink = move source;
// any use of 'source' now is an hard error
or
consume(move source);
// any use of 'source' now is an hard error

is straightforward and intuitive. It always does what it claims to do,
no possibility of errors, no corner-cases.

So what exactly this new fair amount of complexity would be?