Tom Honermann wrote:
> > Going forward, maybe we want to establish guidance that we support
> > only basic transcoding involving UTF-16 and UTF-32, but do not provide
> > all library functionality for those (e.g. std::format, std::to_chars
> > etc.).
>
> I think that is reasonable. Given that we have a precedent, I think motivation
> for a change should be argued in a paper and should be stronger than, "we
> don't think we need it", particularly since, once support for UTF-8/char8_t is
> in place, it is almost trivial to add support for char16_t and char32_t. The
> existing standard libraries already have conversion routines.

General stdlib support aside, I definitely don't think the compiler needs to
be burdened with having to encode into UTF-16 or UTF-32 at compile time.

Esp. when the literal encoding is UTF-8, which means that the compiler
needs to only emit a single NTCS.

(There's nothing wrong with providing constexpr conversions from
u8string_view to u16string and a "reify" function that turns any consteval
basic_string into a constexpt basic_string_view into static storage, but
these are a separate story and we need not concern ourselves with them
while solving our immediate problem.)