Tom Honermann wrote:
> Is support for std::cout specifically required or would support for std::format()
> and std::print() suffice? If std::cout support is specifically required, what
> motivates that requirement?

30 years of "hello world".

It's not 110% required, but it would be nice if it compiled and worked
at least in the case where the string happens to be ASCII.

> During the meeting, we briefly discussed use of an opaque type for the return
> type of name_of() and friends. I would like to see further exploration of this
> idea prior to our next review. I'm envisioning a type something like the
> following (This particular formulation follows existing precedent established by
> the std::filesystem::path native format observers, [fs.path.native.obs]
> <http://eel.is/c++draft/fs.path.native.obs> ).
>
>
> class name {
> std::string_view internal-representation; // exposition only.
> name(/* unspecified */);
> public:
> constexpr std::string string() const; // ordinary literal encoding.
> constexpr std::wstring wstring() const; // wide literal encoding.
> constexpr std::u8string u8string() const; // UTF-8.
> constexpr std::u16string u16string() const; // UTF-16.
> constexpr std::u32string u32string() const; // UTF-32.
> };

I don't think this works for me. There's no way to get a constexpr
char const* from this, and no way to get a constexpr string_view.

(Unless we add a "reification" function that allows a consteval std::string
to survive until runtime.)

The current implementations allow

constexpr char const* s1 = name_of(^float).data(); // NTCS
constexpr std::string_view s2 = name_of(^float);

The above does not.

Unrelated, I don't think we need to bother with char16_t and char32_t.
One Unicode representation is fully enough.