New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-constexpr
destructor removes constexpr
-ness for defaulted assignment operators
#527
Comments
Hello @Ukilele, that looks like an interesting question. From the paragraphs you quote, I agree your interpretation seems correct. If we look at the AST from Clang (compiler-explorer.com/z/K3f5jzscE) we can see that Now, there is one piece missing, which I couldn't find quickly. It does not make sense to mark the assignment operators I can see that eel.is/c++draft/dcl.constexpr#3 does not say that, which is confusing. I'll ask WG21 whether there is some text missing or there is a sub-clause somewhere addressing this behavior. Andreas |
Hi Andreas, I agree that The reason that line 13 fails to compile is, because the destructor of So far I still think that the assignment operators of |
According to https://eel.is/c++draft/dcl.fct.def.default#3, a copy-/move-assignment operator, that is defaulted on its first declaration, is constexpr if possible. And according to https://eel.is/c++draft/dcl.constexpr#3, it is possible to be constexpr when it is not a coroutine. So in all the examples below (
A
,B
,C
,D
,D<true>
,D<false>
) I would expect the assignment operators to be constexpr. But cppinsights only marks the ones ofA
,C
andD<true>
as constexpr. Is the constexpr-ness in the casesB
,D
andD<false>
missing? Or do I miss something?Source code:
Generated insights:
The text was updated successfully, but these errors were encountered: