[lmi] Move decays to copy [Was: When in doubt, prefer the Rule of Five to the Rule of Zero]

[Greg Chicares]

[...this crossed in the mail with your reply, but let's see if we agree...]

On 7/12/22 16:18, Greg Chicares wrote:
> On 7/11/22 22:12, Vadim Zeitlin wrote:
[...]
>>>>  [... gpt_state special members ...] it might
>>>> still be nice to explain why do we want to forbid assigning to it...
> 
> I was just looking at that one, so let me share the question I'm
> pondering. This class has a data member:
>     gpt_state state_                 {};
> of a class that has custom copy operations (because defaulting them
> would not work), and I've never even thought of implementing move
> operations there. Should gpt_server be non-movable because it contains
> a non-movable member, or does the language quietly substitute copy
> semantics for that member so that a defaulted move of the owning
> class is valid?

The answer is "Yes".

Class gpt_state declares no "move" special members. That doesn't
mean it's an error to ask to move gpt_server's gpt_state member;
it just means that such a request will be fulfilled by copying
that member.

There might be good reason to implement move semantics for class
gpt_state, for the sake of efficiency, but that's not necessary
for correctness.