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

[Suman Kar]

On Tue, May 29, 2012 at 3:51 AM, Howard Hinnant <hhinnant at apple.com> wrote:
> On May 28, 2012, at 4:26 PM, Suman Kar wrote:
>
>> A quick question:
>>
>> struct A {};
>>
>> struct B : A { ~B() {} };
>>
>> A makeA() {
>> A a;
>> return a;
>> }
>>
>> B makeB() {
>> B b;
>> return b;
>> }
>>
>> int main() {
>> A a = makeA();
>> B b = makeB();
>> }
>>
>> Is it correct to assume that A will be moved and B will not?
>
> Yes.
>
>> Should a
>> diagnostic be required for the call to makeB?
>
> No.  B should be allowed to to suppress an implicit move constructor.  The implicit version might do the wrong thing.
>
> But you can create your own compile-time diagnostic.
>

Right. My point was that the behavior changes subtly across a
hierarchy. This can be a spot of bother when designing. I understand
the reason -- since the user *defined* a destructor somewhere down the
hierarchy, the compiler (correctly) stays away from (using a crystal
ball and) moving stuff.

There is also this tendency among beginning programmers to define an
empty destructor (for no good reason perhaps and I've seen quite a few
such cases with seasoned ones too). Suddenly, a no-op definition
starts costing more!

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.

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? Also, is

   'When the move constructor is not implicitly declared or explicitly
   supplied'

standardese for suppressed/inhibited/deprecated?

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

Regards,
Suman