The traits that detect nothrow constructibility are buggy because they are influenced by whether the object has a nothrow dtor; destruction is invoked at the end of evaluation of the full expression in the noexcept( ... ) operator. They all use the pattern of constructing a temporary inside noexcept, whereas they should be using placement new: struct X { X() noexcept; ~X(); }; static_assert( noexcept( X() ), "fails because of ~X" ); static_assert( noexcept(new (nullptr) X()), "works" );
I think this is by design, see the thread beginning with c++std-lib-30698 I've been surprised by that reasoning several times e.g. http://gcc.gnu.org/ml/gcc-help/2011-11/msg00015.html
Daniel should resolve this.
By the way, Jon, I think we should audit the library a little more systematically vs PR50043 (assuming that, unfortunately, isn't done in time for 4.7) and in case add explicit noexcept.
yes, I keep forgetting that noexcept should be implied on dtors now
(In reply to comment #1) > I think this is by design, see the thread beginning with c++std-lib-30698 > > I've been surprised by that reasoning several times e.g. > http://gcc.gnu.org/ml/gcc-help/2011-11/msg00015.html I see the thread. I don't see anything in the thread that supports the idea that it should behave this way, but maybe I'm missing something.
c++std-lib-30708 has Daniel's explanation of his interpretation, as implemented in GCC. FWIW I prefer your interpretation, but will peace Daniel to comment further
Please note that this issue here is a simply a dup of bug 51295, which is a compiler defect and *not* a library problem. See [class.dtor] p3: "A declaration of a destructor that does not have an exception-specification is implicitly considered to have the same exception-specification as an implicit declaration (15.4)." I hadn't looked at the actual example until Dave was describing effects on the LWG reflector that are obviously in contradiction to the core language. I repeat: The test case should be well-formed with the existing is_constructible definition once the compiler defect is fixed.
Corrected testcase: struct X { X() noexcept; ~X() noexcept(false); }; static_assert( noexcept( X() ), "fails because of ~X" ); static_assert( noexcept(new (nullptr) X()), "works" );
Ah good, let's resolve as duplicate then. Thanks Daniel. *** This bug has been marked as a duplicate of bug 51295 ***
(In reply to comment #9) > Ah good, let's resolve as duplicate then. Thanks Daniel. > > *** This bug has been marked as a duplicate of bug 51295 *** But wait! The example I gave was not a test case! The point was that it shows a defect in traits that detect nothrow constructibility. This bug should be re-opened.
Agreed (though it should probably be suspended when there's an LWG issue) My "corrected" testcase wasn't right, here's another attempt: #include <type_traits> struct X { X() noexcept; ~X() noexcept(false); }; static_assert(std::is_nothrow_constructible<X>::value, "fails because of ~X");
Thus Daniel was wrong when he said that fixing 51295 automatically renders correct his current implementation of the trait? I suspect there is a misunderstanding here: we are in control of both compiler and library, thus, if I understood Daniel correctly, there is no need to keep this issue open, as if to force some sort of workaround on the library side. Unless we *really* decide that we don't want to wait for the front-end to be fixed. Anyway, I'm off, anything Daniel wants to do for his trait, it's Ok with me.
The issue is what the "correct" definition of the trait is, but I think we need a DR to clarify it
This is http://cplusplus.github.com/LWG/lwg-active.html#2116 so let's suspend this.
*** Bug 54722 has been marked as a duplicate of this bug. ***
*** Bug 56191 has been marked as a duplicate of this bug. ***
(In reply to Jonathan Wakely from comment #14) > This is http://cplusplus.github.com/LWG/lwg-active.html#2116 so let's > suspend this. Updated link: https://wg21.link/lwg2116
Related to https://cplusplus.github.io/CWG/issues/2886.html also.