I tend to believe that the U(U&&) case in the example is a GCC bug. It shall be noexcept also.
- why? user-defined destructor prevents the move ctor, and copy ctor generation (which is deprecated in this case) produces noexcept(false) because it has to call vector's copy ctor. If you default U(U&&), you get a "true" there. --Cubbi (talk) 11:09, 20 April 2014 (PDT)
Would it be worthwhile to add a line to the example to show how a constructor only may be tested for noexcept-ness?
I found that
... noexcept(T()) ...
tests BOTH, destructor AND constructor for noexcept. What I finally came up with to test the noexcept-ness of a constructor (default or other, with appropriate arguments inside the parentheses) is this:
... noexcept(new(nullptr) T()) ...
Is there a more appropriate way to achieve that effect?
Also, I think the combined test in the first case is not obvious. But if such an expression were to be evaluated at run-time the destructor would run afterwards as part of removing the temporary, hence noexcept (as compile-time operator) tests noexcept-ness of the destructor too.
(I know very well that throwing destructors are a bad idea in general, but reliably testing noexcept-ness of a constructor ONLY might sometimes be what you need.)
- Good point. When std::is_nothrow_default_constructible was implemented by both GNU and libc++, the implementors made the same mistake (using noexcept(T())) as the test), which resulted in GCC bug 51452 and LWG issue 2116. This definitely needs to be noted on the std::is_nothrow_default_constructible page, and the example here that tests T() should mention that it tests both constructor and destructor. --Cubbi (talk) 10:14, 25 October 2015 (PDT)