[ 2015-02 Cologne ]

Core wording should say "this kind of thing is ill-formed, no diagnostic required"

The BaseCharacteristic for is_constructible is defined in terms of the well-formedness of a declaration for an invented variable. The well-formedness of the described declaration itself may change for the same set of arguments because of the introduction of default arguments.

In the following program, there appears to be conflicting definitions of a specialization of std::is_constructible; however, it seems that this situation is caused without a user violation of the library requirements or the ODR. There is a similar issue with is_convertible, result_of and others.

a.cc:

#include <type_traits>
struct A { A(int, int); };
const std::false_type& x1 = std::is_constructible<A, int>();

int main() { }

b.cc:

#include <type_traits>
struct A { A(int, int); };

inline A::A(int, int = 0) { }

const std::true_type& x2 = std::is_constructible<A, int>();

Presumably this program should invoke undefined behaviour, but the Library specification doesn't say that.