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)
User defined dtor does not prevent move ctor generation in the case of T. good spot about the defaulting U(U&&) 11:31, 20 April 2014 (PDT)
Ah ok. I got it. The copy constructor is nothrow in the case of T. Thanks! 11:33, 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.)

Mwe (talk) 09:42, 25 October 2015 (PDT)

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)