Declaring defaulted assignment operator as constexpr: which compiler is right?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








31















Consider



struct A1 
constexpr A1& operator=(const A1&) = default;
~A1()
;
struct A2
constexpr A2& operator=(const A2&) = default;
~A2() = default;
;
struct A3
~A3() = default;
constexpr A3& operator=(const A3&) = default;
;


GCC and MSVC accept all three structs. Clang rejects A1 and A2 (but accepts A3), with the following error message:




<source>:2:5: error: defaulted definition of copy assignment operator is not constexpr
constexpr A1& operator=(const A1&) = default;
^
<source>:6:5: error: defaulted definition of copy assignment operator is not constexpr
constexpr A2& operator=(const A2&) = default;
^
2 errors generated.



(live demo)



Which compiler is correct, and why?










share|improve this question






















  • Good question. The following is only a guess... We know that constexpr in functions doesn't mean const. It means whether or not that function can be computed at compile time. The silently created copy assignment operator is not preceded by a constexpr. This means that the constexpr you have is an overload to the silently created one. The overload however cannot be defaulted, which explains the error. Check out the following 3 code examples: 1) (clang) rextester.com/WLGFD87794, 2) (gcc) rextester.com/RMWQ86797, 3) (vc++) rextester.com/MXIHQ50551 .

    – Constantinos Glynos
    Mar 15 at 12:43

















31















Consider



struct A1 
constexpr A1& operator=(const A1&) = default;
~A1()
;
struct A2
constexpr A2& operator=(const A2&) = default;
~A2() = default;
;
struct A3
~A3() = default;
constexpr A3& operator=(const A3&) = default;
;


GCC and MSVC accept all three structs. Clang rejects A1 and A2 (but accepts A3), with the following error message:




<source>:2:5: error: defaulted definition of copy assignment operator is not constexpr
constexpr A1& operator=(const A1&) = default;
^
<source>:6:5: error: defaulted definition of copy assignment operator is not constexpr
constexpr A2& operator=(const A2&) = default;
^
2 errors generated.



(live demo)



Which compiler is correct, and why?










share|improve this question






















  • Good question. The following is only a guess... We know that constexpr in functions doesn't mean const. It means whether or not that function can be computed at compile time. The silently created copy assignment operator is not preceded by a constexpr. This means that the constexpr you have is an overload to the silently created one. The overload however cannot be defaulted, which explains the error. Check out the following 3 code examples: 1) (clang) rextester.com/WLGFD87794, 2) (gcc) rextester.com/RMWQ86797, 3) (vc++) rextester.com/MXIHQ50551 .

    – Constantinos Glynos
    Mar 15 at 12:43













31












31








31


2






Consider



struct A1 
constexpr A1& operator=(const A1&) = default;
~A1()
;
struct A2
constexpr A2& operator=(const A2&) = default;
~A2() = default;
;
struct A3
~A3() = default;
constexpr A3& operator=(const A3&) = default;
;


GCC and MSVC accept all three structs. Clang rejects A1 and A2 (but accepts A3), with the following error message:




<source>:2:5: error: defaulted definition of copy assignment operator is not constexpr
constexpr A1& operator=(const A1&) = default;
^
<source>:6:5: error: defaulted definition of copy assignment operator is not constexpr
constexpr A2& operator=(const A2&) = default;
^
2 errors generated.



(live demo)



Which compiler is correct, and why?










share|improve this question














Consider



struct A1 
constexpr A1& operator=(const A1&) = default;
~A1()
;
struct A2
constexpr A2& operator=(const A2&) = default;
~A2() = default;
;
struct A3
~A3() = default;
constexpr A3& operator=(const A3&) = default;
;


GCC and MSVC accept all three structs. Clang rejects A1 and A2 (but accepts A3), with the following error message:




<source>:2:5: error: defaulted definition of copy assignment operator is not constexpr
constexpr A1& operator=(const A1&) = default;
^
<source>:6:5: error: defaulted definition of copy assignment operator is not constexpr
constexpr A2& operator=(const A2&) = default;
^
2 errors generated.



(live demo)



Which compiler is correct, and why?







c++ language-lawyer c++17 constexpr






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Mar 15 at 12:04









cpplearnercpplearner

5,68622342




5,68622342












  • Good question. The following is only a guess... We know that constexpr in functions doesn't mean const. It means whether or not that function can be computed at compile time. The silently created copy assignment operator is not preceded by a constexpr. This means that the constexpr you have is an overload to the silently created one. The overload however cannot be defaulted, which explains the error. Check out the following 3 code examples: 1) (clang) rextester.com/WLGFD87794, 2) (gcc) rextester.com/RMWQ86797, 3) (vc++) rextester.com/MXIHQ50551 .

    – Constantinos Glynos
    Mar 15 at 12:43

















  • Good question. The following is only a guess... We know that constexpr in functions doesn't mean const. It means whether or not that function can be computed at compile time. The silently created copy assignment operator is not preceded by a constexpr. This means that the constexpr you have is an overload to the silently created one. The overload however cannot be defaulted, which explains the error. Check out the following 3 code examples: 1) (clang) rextester.com/WLGFD87794, 2) (gcc) rextester.com/RMWQ86797, 3) (vc++) rextester.com/MXIHQ50551 .

    – Constantinos Glynos
    Mar 15 at 12:43
















Good question. The following is only a guess... We know that constexpr in functions doesn't mean const. It means whether or not that function can be computed at compile time. The silently created copy assignment operator is not preceded by a constexpr. This means that the constexpr you have is an overload to the silently created one. The overload however cannot be defaulted, which explains the error. Check out the following 3 code examples: 1) (clang) rextester.com/WLGFD87794, 2) (gcc) rextester.com/RMWQ86797, 3) (vc++) rextester.com/MXIHQ50551 .

– Constantinos Glynos
Mar 15 at 12:43





Good question. The following is only a guess... We know that constexpr in functions doesn't mean const. It means whether or not that function can be computed at compile time. The silently created copy assignment operator is not preceded by a constexpr. This means that the constexpr you have is an overload to the silently created one. The overload however cannot be defaulted, which explains the error. Check out the following 3 code examples: 1) (clang) rextester.com/WLGFD87794, 2) (gcc) rextester.com/RMWQ86797, 3) (vc++) rextester.com/MXIHQ50551 .

– Constantinos Glynos
Mar 15 at 12:43












2 Answers
2






active

oldest

votes


















24














I think all three compilers are wrong.



[dcl.fct.def.default]/3 says:




An explicitly-defaulted function that is not defined as deleted may be declared constexpr or consteval only if it would have been implicitly declared as constexpr. If a function is explicitly defaulted on its first declaration, it is implicitly considered to be constexpr if the implicit declaration would be.




When is the copy assignment operator implicitly declared constexpr? [class.copy.assign]/10:




The implicitly-defined copy/move assignment operator is constexpr if



  • X is a literal type, and

  • [...]



Where a literal type is, from [basic.types]/10:




A type is a literal type if it is:



  • [...]


  • a possibly cv-qualified class type that has all of the following properties:



    • it has a trivial destructor,

    • [...]




A1 doesn't have a trivial destructor, so its implicit copy assignment operator isn't constexpr. Hence that copy assignment operator is ill-formed (gcc and msvc bug to accept).



The other two are fine, and it's a clang bug to reject A2.




Note the last bit of [dcl.fct.def.default] that I quoted. You don't actually have to add constexpr if you're explicitly defaulting. It would be implicitly constexpr where that is possible.






share|improve this answer























  • Adding constexpr should give you an error if it isn't constexpr, which is something that could be quite useful.

    – Yakk - Adam Nevraumont
    Mar 15 at 18:01



















8














The C++17 standard states:




15.8.2 Copy/move assignment operator [class.copy.assign]

...



10 A copy/move assignment operator for a class X that is defaulted and not defined as deleted is implicitly defined when it is odr-used (6.2) (e.g., when it is selected by overload resolution to assign to an object of its class type) or when it is explicitly defaulted after its first declaration. The implicitly-defined copy/move assignment operator is constexpr if

(10.1) — X is a literal type, and

(10.2) — the assignment operator selected to copy/move each direct base class subobject is a constexpr function, and

(10.3) — for each non-static data member of X that is of class type (or array thereof), the assignment operator selected to copy/move that member is a constexpr function.




The copy-assignment operator satisfies the above requirements in two of the cases. In the first case, we have a non-literal type because of the non-trivial destructor.



So I believe Clang is wrong to reject the code in the second case.



There is a bug filed with Clang titled: Defaulted destructor prevents using constexpr on defaulted copy/move-operator which shows the same symptoms as the code in the OP.



The comments from the bug report state:




When defaulted destructor is commented out (i.e. not user declared), then errors cease to exist.




and




The problem also goes away if you declare the destructor before the copy assignment operator.




This is true of the code in the question as well.



As @YSC points out, another relevant quote here is:[dcl.fct.def.default]/3 which states:




An explicitly-defaulted function that is not defined as deleted may be declared constexpr or consteval only if it would have been implicitly declared as constexpr. If a function is explicitly defaulted on its first declaration, it is implicitly considered to be constexpr if the implicit declaration would be.







share|improve this answer

























  • related: eel.is/c++draft/dcl.fct.def.default#3 and eel.is/c++draft/class.copy.assign#10 (already quoted)

    – YSC
    Mar 15 at 12:37












  • May I translate this into: Changing the order of destructor and copy assignment definition (like OP did for struct A2 and struct A3) shouldn't have any effect (for compiling the code without error)?

    – Scheff
    Mar 15 at 12:43











Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55182242%2fdeclaring-defaulted-assignment-operator-as-constexpr-which-compiler-is-right%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









24














I think all three compilers are wrong.



[dcl.fct.def.default]/3 says:




An explicitly-defaulted function that is not defined as deleted may be declared constexpr or consteval only if it would have been implicitly declared as constexpr. If a function is explicitly defaulted on its first declaration, it is implicitly considered to be constexpr if the implicit declaration would be.




When is the copy assignment operator implicitly declared constexpr? [class.copy.assign]/10:




The implicitly-defined copy/move assignment operator is constexpr if



  • X is a literal type, and

  • [...]



Where a literal type is, from [basic.types]/10:




A type is a literal type if it is:



  • [...]


  • a possibly cv-qualified class type that has all of the following properties:



    • it has a trivial destructor,

    • [...]




A1 doesn't have a trivial destructor, so its implicit copy assignment operator isn't constexpr. Hence that copy assignment operator is ill-formed (gcc and msvc bug to accept).



The other two are fine, and it's a clang bug to reject A2.




Note the last bit of [dcl.fct.def.default] that I quoted. You don't actually have to add constexpr if you're explicitly defaulting. It would be implicitly constexpr where that is possible.






share|improve this answer























  • Adding constexpr should give you an error if it isn't constexpr, which is something that could be quite useful.

    – Yakk - Adam Nevraumont
    Mar 15 at 18:01
















24














I think all three compilers are wrong.



[dcl.fct.def.default]/3 says:




An explicitly-defaulted function that is not defined as deleted may be declared constexpr or consteval only if it would have been implicitly declared as constexpr. If a function is explicitly defaulted on its first declaration, it is implicitly considered to be constexpr if the implicit declaration would be.




When is the copy assignment operator implicitly declared constexpr? [class.copy.assign]/10:




The implicitly-defined copy/move assignment operator is constexpr if



  • X is a literal type, and

  • [...]



Where a literal type is, from [basic.types]/10:




A type is a literal type if it is:



  • [...]


  • a possibly cv-qualified class type that has all of the following properties:



    • it has a trivial destructor,

    • [...]




A1 doesn't have a trivial destructor, so its implicit copy assignment operator isn't constexpr. Hence that copy assignment operator is ill-formed (gcc and msvc bug to accept).



The other two are fine, and it's a clang bug to reject A2.




Note the last bit of [dcl.fct.def.default] that I quoted. You don't actually have to add constexpr if you're explicitly defaulting. It would be implicitly constexpr where that is possible.






share|improve this answer























  • Adding constexpr should give you an error if it isn't constexpr, which is something that could be quite useful.

    – Yakk - Adam Nevraumont
    Mar 15 at 18:01














24












24








24







I think all three compilers are wrong.



[dcl.fct.def.default]/3 says:




An explicitly-defaulted function that is not defined as deleted may be declared constexpr or consteval only if it would have been implicitly declared as constexpr. If a function is explicitly defaulted on its first declaration, it is implicitly considered to be constexpr if the implicit declaration would be.




When is the copy assignment operator implicitly declared constexpr? [class.copy.assign]/10:




The implicitly-defined copy/move assignment operator is constexpr if



  • X is a literal type, and

  • [...]



Where a literal type is, from [basic.types]/10:




A type is a literal type if it is:



  • [...]


  • a possibly cv-qualified class type that has all of the following properties:



    • it has a trivial destructor,

    • [...]




A1 doesn't have a trivial destructor, so its implicit copy assignment operator isn't constexpr. Hence that copy assignment operator is ill-formed (gcc and msvc bug to accept).



The other two are fine, and it's a clang bug to reject A2.




Note the last bit of [dcl.fct.def.default] that I quoted. You don't actually have to add constexpr if you're explicitly defaulting. It would be implicitly constexpr where that is possible.






share|improve this answer













I think all three compilers are wrong.



[dcl.fct.def.default]/3 says:




An explicitly-defaulted function that is not defined as deleted may be declared constexpr or consteval only if it would have been implicitly declared as constexpr. If a function is explicitly defaulted on its first declaration, it is implicitly considered to be constexpr if the implicit declaration would be.




When is the copy assignment operator implicitly declared constexpr? [class.copy.assign]/10:




The implicitly-defined copy/move assignment operator is constexpr if



  • X is a literal type, and

  • [...]



Where a literal type is, from [basic.types]/10:




A type is a literal type if it is:



  • [...]


  • a possibly cv-qualified class type that has all of the following properties:



    • it has a trivial destructor,

    • [...]




A1 doesn't have a trivial destructor, so its implicit copy assignment operator isn't constexpr. Hence that copy assignment operator is ill-formed (gcc and msvc bug to accept).



The other two are fine, and it's a clang bug to reject A2.




Note the last bit of [dcl.fct.def.default] that I quoted. You don't actually have to add constexpr if you're explicitly defaulting. It would be implicitly constexpr where that is possible.







share|improve this answer












share|improve this answer



share|improve this answer










answered Mar 15 at 12:40









BarryBarry

187k21330607




187k21330607












  • Adding constexpr should give you an error if it isn't constexpr, which is something that could be quite useful.

    – Yakk - Adam Nevraumont
    Mar 15 at 18:01


















  • Adding constexpr should give you an error if it isn't constexpr, which is something that could be quite useful.

    – Yakk - Adam Nevraumont
    Mar 15 at 18:01

















Adding constexpr should give you an error if it isn't constexpr, which is something that could be quite useful.

– Yakk - Adam Nevraumont
Mar 15 at 18:01






Adding constexpr should give you an error if it isn't constexpr, which is something that could be quite useful.

– Yakk - Adam Nevraumont
Mar 15 at 18:01














8














The C++17 standard states:




15.8.2 Copy/move assignment operator [class.copy.assign]

...



10 A copy/move assignment operator for a class X that is defaulted and not defined as deleted is implicitly defined when it is odr-used (6.2) (e.g., when it is selected by overload resolution to assign to an object of its class type) or when it is explicitly defaulted after its first declaration. The implicitly-defined copy/move assignment operator is constexpr if

(10.1) — X is a literal type, and

(10.2) — the assignment operator selected to copy/move each direct base class subobject is a constexpr function, and

(10.3) — for each non-static data member of X that is of class type (or array thereof), the assignment operator selected to copy/move that member is a constexpr function.




The copy-assignment operator satisfies the above requirements in two of the cases. In the first case, we have a non-literal type because of the non-trivial destructor.



So I believe Clang is wrong to reject the code in the second case.



There is a bug filed with Clang titled: Defaulted destructor prevents using constexpr on defaulted copy/move-operator which shows the same symptoms as the code in the OP.



The comments from the bug report state:




When defaulted destructor is commented out (i.e. not user declared), then errors cease to exist.




and




The problem also goes away if you declare the destructor before the copy assignment operator.




This is true of the code in the question as well.



As @YSC points out, another relevant quote here is:[dcl.fct.def.default]/3 which states:




An explicitly-defaulted function that is not defined as deleted may be declared constexpr or consteval only if it would have been implicitly declared as constexpr. If a function is explicitly defaulted on its first declaration, it is implicitly considered to be constexpr if the implicit declaration would be.







share|improve this answer

























  • related: eel.is/c++draft/dcl.fct.def.default#3 and eel.is/c++draft/class.copy.assign#10 (already quoted)

    – YSC
    Mar 15 at 12:37












  • May I translate this into: Changing the order of destructor and copy assignment definition (like OP did for struct A2 and struct A3) shouldn't have any effect (for compiling the code without error)?

    – Scheff
    Mar 15 at 12:43















8














The C++17 standard states:




15.8.2 Copy/move assignment operator [class.copy.assign]

...



10 A copy/move assignment operator for a class X that is defaulted and not defined as deleted is implicitly defined when it is odr-used (6.2) (e.g., when it is selected by overload resolution to assign to an object of its class type) or when it is explicitly defaulted after its first declaration. The implicitly-defined copy/move assignment operator is constexpr if

(10.1) — X is a literal type, and

(10.2) — the assignment operator selected to copy/move each direct base class subobject is a constexpr function, and

(10.3) — for each non-static data member of X that is of class type (or array thereof), the assignment operator selected to copy/move that member is a constexpr function.




The copy-assignment operator satisfies the above requirements in two of the cases. In the first case, we have a non-literal type because of the non-trivial destructor.



So I believe Clang is wrong to reject the code in the second case.



There is a bug filed with Clang titled: Defaulted destructor prevents using constexpr on defaulted copy/move-operator which shows the same symptoms as the code in the OP.



The comments from the bug report state:




When defaulted destructor is commented out (i.e. not user declared), then errors cease to exist.




and




The problem also goes away if you declare the destructor before the copy assignment operator.




This is true of the code in the question as well.



As @YSC points out, another relevant quote here is:[dcl.fct.def.default]/3 which states:




An explicitly-defaulted function that is not defined as deleted may be declared constexpr or consteval only if it would have been implicitly declared as constexpr. If a function is explicitly defaulted on its first declaration, it is implicitly considered to be constexpr if the implicit declaration would be.







share|improve this answer

























  • related: eel.is/c++draft/dcl.fct.def.default#3 and eel.is/c++draft/class.copy.assign#10 (already quoted)

    – YSC
    Mar 15 at 12:37












  • May I translate this into: Changing the order of destructor and copy assignment definition (like OP did for struct A2 and struct A3) shouldn't have any effect (for compiling the code without error)?

    – Scheff
    Mar 15 at 12:43













8












8








8







The C++17 standard states:




15.8.2 Copy/move assignment operator [class.copy.assign]

...



10 A copy/move assignment operator for a class X that is defaulted and not defined as deleted is implicitly defined when it is odr-used (6.2) (e.g., when it is selected by overload resolution to assign to an object of its class type) or when it is explicitly defaulted after its first declaration. The implicitly-defined copy/move assignment operator is constexpr if

(10.1) — X is a literal type, and

(10.2) — the assignment operator selected to copy/move each direct base class subobject is a constexpr function, and

(10.3) — for each non-static data member of X that is of class type (or array thereof), the assignment operator selected to copy/move that member is a constexpr function.




The copy-assignment operator satisfies the above requirements in two of the cases. In the first case, we have a non-literal type because of the non-trivial destructor.



So I believe Clang is wrong to reject the code in the second case.



There is a bug filed with Clang titled: Defaulted destructor prevents using constexpr on defaulted copy/move-operator which shows the same symptoms as the code in the OP.



The comments from the bug report state:




When defaulted destructor is commented out (i.e. not user declared), then errors cease to exist.




and




The problem also goes away if you declare the destructor before the copy assignment operator.




This is true of the code in the question as well.



As @YSC points out, another relevant quote here is:[dcl.fct.def.default]/3 which states:




An explicitly-defaulted function that is not defined as deleted may be declared constexpr or consteval only if it would have been implicitly declared as constexpr. If a function is explicitly defaulted on its first declaration, it is implicitly considered to be constexpr if the implicit declaration would be.







share|improve this answer















The C++17 standard states:




15.8.2 Copy/move assignment operator [class.copy.assign]

...



10 A copy/move assignment operator for a class X that is defaulted and not defined as deleted is implicitly defined when it is odr-used (6.2) (e.g., when it is selected by overload resolution to assign to an object of its class type) or when it is explicitly defaulted after its first declaration. The implicitly-defined copy/move assignment operator is constexpr if

(10.1) — X is a literal type, and

(10.2) — the assignment operator selected to copy/move each direct base class subobject is a constexpr function, and

(10.3) — for each non-static data member of X that is of class type (or array thereof), the assignment operator selected to copy/move that member is a constexpr function.




The copy-assignment operator satisfies the above requirements in two of the cases. In the first case, we have a non-literal type because of the non-trivial destructor.



So I believe Clang is wrong to reject the code in the second case.



There is a bug filed with Clang titled: Defaulted destructor prevents using constexpr on defaulted copy/move-operator which shows the same symptoms as the code in the OP.



The comments from the bug report state:




When defaulted destructor is commented out (i.e. not user declared), then errors cease to exist.




and




The problem also goes away if you declare the destructor before the copy assignment operator.




This is true of the code in the question as well.



As @YSC points out, another relevant quote here is:[dcl.fct.def.default]/3 which states:




An explicitly-defaulted function that is not defined as deleted may be declared constexpr or consteval only if it would have been implicitly declared as constexpr. If a function is explicitly defaulted on its first declaration, it is implicitly considered to be constexpr if the implicit declaration would be.








share|improve this answer














share|improve this answer



share|improve this answer








edited Mar 15 at 12:54

























answered Mar 15 at 12:35









P.WP.W

18.7k41859




18.7k41859












  • related: eel.is/c++draft/dcl.fct.def.default#3 and eel.is/c++draft/class.copy.assign#10 (already quoted)

    – YSC
    Mar 15 at 12:37












  • May I translate this into: Changing the order of destructor and copy assignment definition (like OP did for struct A2 and struct A3) shouldn't have any effect (for compiling the code without error)?

    – Scheff
    Mar 15 at 12:43

















  • related: eel.is/c++draft/dcl.fct.def.default#3 and eel.is/c++draft/class.copy.assign#10 (already quoted)

    – YSC
    Mar 15 at 12:37












  • May I translate this into: Changing the order of destructor and copy assignment definition (like OP did for struct A2 and struct A3) shouldn't have any effect (for compiling the code without error)?

    – Scheff
    Mar 15 at 12:43
















related: eel.is/c++draft/dcl.fct.def.default#3 and eel.is/c++draft/class.copy.assign#10 (already quoted)

– YSC
Mar 15 at 12:37






related: eel.is/c++draft/dcl.fct.def.default#3 and eel.is/c++draft/class.copy.assign#10 (already quoted)

– YSC
Mar 15 at 12:37














May I translate this into: Changing the order of destructor and copy assignment definition (like OP did for struct A2 and struct A3) shouldn't have any effect (for compiling the code without error)?

– Scheff
Mar 15 at 12:43





May I translate this into: Changing the order of destructor and copy assignment definition (like OP did for struct A2 and struct A3) shouldn't have any effect (for compiling the code without error)?

– Scheff
Mar 15 at 12:43

















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55182242%2fdeclaring-defaulted-assignment-operator-as-constexpr-which-compiler-is-right%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?