Proposed resolution:

This wording is relative to N5014.

1. Modify [tab:meta.unary.prop], Table 54 Type property predicates, as indicated:

   Template	Condition	Preconditions
   ...	...	...
   template<class T, class... Args> struct is_nothrow_constructible;	is_constructible_v<T, Args...> is `true` and the variable definition for `is_constructible`, as defined below, contains no potentially-throwing expression ([except.spec]) is known not to throw any exceptions ([expr.unary.noexcept]).	`T` and all types in the template parameter pack `Args` shall be complete types, cv `void`, or arrays of unknown bound.
   ...	...	...

[ 2025-10-18; Arthur provides wording ]

[ 2025-10-17; Reflector poll. ]

Set priority to 3 after reflector poll.

"NAD, this was just a GCC bug."

std::is_nothrow_* traits are currently specified in the form "(some operation) is known not to throw any exceptions". Under the following circumstance, the current specification may be ambiguous:

• a trait detects an explicitly defaulted special member function, and

• the implicit except specification of that function would be noexcept(true), but

• the function is explicitly marked with noexcept(false).

It seems that an implementation may decompose the defaulted special member function and then conclude that the trait should give a true result, or may just use the exception specification which gives a false result.

Implementors seemingly hold different opinions, see GCC Bug 106611 and this blog post.

Perhaps we may need to clarify that the implementation divergence is permitted, or unambiguously specify these traits to give results consistent with exception specifications.