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

[Suman Kar]

On Mon, May 28, 2012 at 7:58 PM, Howard Hinnant <hhinnant at apple.com> wrote:
> On May 28, 2012, at 2:52 AM, Suman Kar wrote:
>
>>> Right.  I mean that they don't exist, just as in C++98/03.  Deleted move members are generally problematic as they inhibit "copying" from rvalues.  If you have valid copy members and deleted move members, you can't return such an object from a function.
>>>
>>
>> Okay, I still can't wrap my head around the last sentence. This looks ominous.
>
[...]
> But:
>
> struct A
> {
>    A() = default;
>    A(const A&) = default;
>    A& operator=(const A&) = default;
> };
>
> A
> make()
> {
>    A a;
>    return a;
> }
>
> int main()
> {
>    A a = make();
> }
>
> Compiles and runs fine.

This looks like (to my ignorant eye) a fine way of not breaking
C++98/03 code. But I am probably oversimplifying.

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? Should a
diagnostic be required for the call to makeB?

I am still going through your and Steve's emails -- I'll try to get
back as soon as I am sure I understand.

Regards,
Suman