Re: [lmi] Move decays to copy

[Greg Chicares]

On 7/12/22 23:19, Vadim Zeitlin wrote:
> On Tue, 12 Jul 2022 21:57:04 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> [...this crossed in the mail with your reply, but let's see if we 
> agree...]
> 
>  I think so, but I still want to clarify something to be absolutely sure:
> 
> GC> Class gpt_state declares no "move" special members. That doesn't
> GC> mean it's an error to ask to move gpt_server's gpt_state member;
> 
>  But how exactly do you ask to move it? You never actually do this. The
> move ctor is used if it's selected by the overload resolution. If it's not
> available, it's not selected and hence not used.

I ask to move the gpt_state member by declaring a defaulted move
ctor for gpt_server, and by writing code for which the language
selects the move ctor as a better match than the copy ctor.

In the "Is this class moveable or not?" subthread, I present
my understanding thus:

  for each data member M
     if M is moveable, move it
     else copy it

and so I believe that I'm asking the language to move each
subobject, if possible.

Is it even possible to ask the language in general to move an
object and in no case to fall back on copying when the object
is actually copyable? (Excluding, that is, special cases like
unique_ptr that are specifically not copyable.) I'm thinking
that this is not possible.