Non-`constexpr` destructor removes `constexpr`-ness for defaulted assignment operators about cppinsights HOT 2 OPEN

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 B's operator is not constexpr. The behavior of C++ Insights matches what Clang thinks.

Now, there is one piece missing, which I couldn't find quickly. It does not make sense to mark the assignment operators constexpr in B since we can never use them in a constexpr context. For example, the compilation fails if you uncomment line 13 in the Compiler Explorer link.

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

from cppinsights.

Hi Andreas,
thanks a lot for your comprehensive response.

I agree that B is a contrived example. Having a class with a constexpr assignment operator but with a non-constexpr destructor is at most useful for theoretical discussions. I just was playing around on cppinsights, because it was not completely clear to me when a defaulted special member function is constexpr or noexcept and your tool is very helpful to find that out!

The reason that line 13 fails to compile is, because the destructor of B is user-provided (showstopper for C++17) and not marked as constexpr (showstopper for C++20). But you are right, I think we can never actually use them in a constexpr context, because we can't use B in a constexpr context, as it's destructor is not constexpr.

So far I still think that the assignment operators of B, D and D<false> should be marked constexpr. But I see that the issue would be on Clang and not on cppinsights.

from cppinsights.