Quuxplusone
commented
10 years ago From my reply on std-proposals:
It is unspecified whether those two typeid expressions produce glvalues
referring to the same object. Therefore this is "a relational or equality
operator where the result is unspecified", so it's non-constant per 5.19/2
bullet 19.
Clang is not deliberately giving this result; I didn't think of this case when
implementing support for typeid expressions in constexpr evaluation. Indeed,
Clang gives the opposite result for this:
constexpr const std::type_info &x() { return typeid(int); }
static_assert(&x() == &x(), "");
... which is arguably ill-formed for the same reason.
We should at least be consistent here; I've also mailed CWG to see if there's
consensus for a less surprising rule here.
static_assert ( & typeid( int ) == & typeid( int ), "" );
As far as I can see, this is valid C++11, and nothing changes for the latest C++14 draft. It does not include any id-expression, lvalue-to-rvalue conversion, nor a typeid with polymorphic operand.
Such a construct would provide value-based compile time type identity. GCC accepts it.