On Wed, 2 Mar 2022 at 14:13, Maciej Cencora <m.cencora_at_[hidden]> wrote:
> > > 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.

Yet it works. That suggests it's a solution.

> > > 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!

I didn't say it does what its name claims, I said it does what it
claims to do. It's a well-documented
facility that's been there since C++11, it's relatively easy to
explain how it works and how to use it,
and after such explanations, the complaints about it
not-really-moving-right-there tend to not come up,
except from language lawyers.

> > ..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?

Well, it's yet another language facility that needs to be learned.
That in and of itself if additional complexity.