On 28/04/2024 17.49, Tom Honermann via SG16 wrote:
> 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.
> };

Are all encodings created equal?

It seems to me that UTF-8 is more important than UTF-16 and UTF-32.
(I thought Windows has stated they're moving towards UTF-8 for their
OS interfaces.)
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.).

Jens