SG16 will hold a telecon on Wednesday, May 26th at 19:30 UTC (timezone conversion).
The agenda is:
Since we did not get to discuss P2295R3 at our last telecon, it
will again retain the top spot on the agenda followed by
P2093R6. Thus, the agenda looks much the same as for the last
telecon (I dropped P2348R0 for now; we won't
realistically get to it).
With regard to P2093R6, the current status is
unchanged; LEWG has referred the paper back to SG16 for further
discussion; please see the LEWG meeting minutes here.
Specifically, LEWG would benefit from additional analysis of previously
deferred questions regarding character encoding concerns,
transcoding requirements (or the lack there of) and the ensuing
consequences (or lack there of).
At our last telecon, we focused on how to handle ill-formed
inputs, but did not much discuss how such inputs arise. Now
has been effectively (though not officially) resolved by P2372R1,
we have a concrete example of how the std::print()
facility itself can produce ill-formed input (assuming that std::print()
transcodes all inputs using the same encoding). I would like to
start with this example as I think it is fundamental to how we
choose to answer the above questions.
At issue is the encoding used by chrono formatters specified with the L option to request a locale specific form. The example above contains the %p specifier with the L option. In a Chinese locale the desired translation of "PM" is "下午", but the locale will provide the translation in the locale encoding. As specified in P2093R6, if the literal encoding is UTF-8, than std::print() will expect the translation to be provided in UTF-8, but if the locale is not UTF-8-based (e.g., Big5; perhaps Shift-JIS for the Japanese 午後 translation), then the result is mojibake.
These are possible directions we can investigate to resolve the encoding concerns.