[cfe-dev] Move constructor forces copy assignment to be implicitly defaulted?

[Howard Hinnant]

On May 29, 2012, at 12:35 PM, Suman Kar wrote:

> Let me summarize my understanding (along with what you've already
> written) w.r.t move members:
> 
> [1] While both copy and move members can be implicitly
> defaulted/deleted only move members can be suppressed.
> [2] A move member can never be implicitly defined to be deleted
> because of the presence of a copy member or a destructor.

Sounds right to me.

> 
> Finally, there's this bit about 12.8/9 that I need help with:
> 
>    When the move constructor is not implicitly declared or explicitly
>    supplied, expressions that otherwise would have invoked the move
>    constructor may instead invoke a copy constructor.
> 
> This, I believe, keeps the compiler happy about compiling the example
> I posted?

Yes.

> Also, is
> 
>    'When the move constructor is not implicitly declared or explicitly
>    supplied'
> 
> standardese for suppressed/inhibited/deprecated?

Yes for suppressed/inhibited.  Deprecated means something different.  When something in the standard is deprecated, it means that it might be removed in a future version of the standard.

> 
> Is it correct to consider the case where move members are deprecated
> as C++98/03 fallback mode?

It is correct to consider the case where move members are suppressed/inhibited/absent as just like you would write in C++98/03.

Howard