Hi Peter and other unicoders,

This is an interesting idea but as Corentin already pointed out the name is just a convention so I'm not sure how it is supposed to work. The transcoding solution on the other hand is implementable, possibly in multiple ways. I initially implemented it for MSVC/Windows but someone contributed an implementation for libstdc++ where transcoding is normally unnecessary but it's still cool that it works. The proposed resolution should probably say something for the case when transcoding is impossible which can happen with weird user-defined locales. A simple solution is to fallback to no transcoding.

Cheers,
Victor

On Thu, Jun 17, 2021 at 1:57 PM Peter Brett via SG16 <sg16@lists.isocpp.org> wrote:
Hi all,

The current proposed resolution for LWG3565 (https://wg21.link/LWG3565)
involves transcoding from the locale encoding to UTF-8.  This makes me a
little uncomfortable.

Is it possible instead to say that, if the string literal encoding is
UTF-8, then the effective locale is _as if_ the specified or global
locale was modified by replacing the associated codeset with UTF-8?

So, the following code:

    std::locale l1("Russian.1251");
    auto s = std::format(l1, "День недели: {:L}", std::chrono::Monday);

Would behave as if replaced by:

    std::locale l1("Russian.1251");
    std::locale l2(l1, std::locale("Russian.UTF-8"), locale::time);
    auto s = std::format(l2, "День недели: {:L}", std::chrono::Monday);

This would permit an implementation that has UTF-8 locale data available
to use it directly, rather than being required to use the 1251 codeset
locale data and transcode in order to conform to the standard.

                             Peter

P.S. How would one go about writing a locale object that customizes
chrono formatting with std::format?  Does anyone have a code sample?
--
SG16 mailing list
SG16@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16