If nullptr_t isn't a keyword, why are char16_t and char32_t?

Question

As discussed at Why is nullptr_t not a keyword, it is better to avoid introducing new keywords because they can break backward compatibility.

Why then are char16_t and char32_t keywords, when they could just as well have been defined like so?

namespace std {     typedef decltype(u'q') char16_t;     typedef decltype(U'q') char32_t; } 

Answer 1

The proposal itself explains why: to allow overloading with the underlying types of uint_least16_t and uint_least32_t. If they were typedefed this wouldn't be possible.

Define char16_t to be a distinct new type, that has the same size and representation as uint_least16_t. Likewise, define char32_t to be a distinct new type, that has the same size and representation as uint_least32_t.

[N1040 defined char16_t and char32_t as typedefs to uint_least16_t and uint_least32_t, which make overloading on these characters impossible.]

As for why they aren't in the std namespace, this is for compatibility with the original C proposal. C++ prohibits the C definitions from appearing in its own version of <cuchar>

[c.strings] / 3

The headers shall not define the types char16_t, char32_t, and wchar_t (2.11).

The types then would need to be global typedefs, which carries its own set of issues such as

typedef decltype(u'q') char16_t;  namespace foo {   typedef int char16_t; } 

The reason for std::nullptr_t not being a keyword can be found in the question you linked

We do not expect to see much direct use of nullptr_t in real programs.

making nullptr_t the real exception here.