On 4/29/24 4:21 PM, Peter Dimov via SG16 wrote:
> 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.)

Agreed.

Tom.