I think there is an issue with formatting of stacktrace for wide streams
as proposed in P2693R0. The paper proposes that formatting support be
provided as-if by an invocation of to_string for basic_stacktrace and
stacktrace_entry objects. However, to_string produces a std::string
which, I think (my grasp of the inner workings of std::format is not
strong), can't be formatted to a wide string (either directly or via the
format context). Likewise, there is no to_wstring overload defined for
basic_stacktrace and stacktrace_entry.

I don't think we should try to backdoor conversions from std::string to
std::wstring as part of resolving this. The simplest solution seems to
be to add to_wstring overloads for basic_stacktrace and stacktrace_entry
and then to modify the formatter specializations to use to_string or
to_wstring accordingly.

Tangent: It looks like the operator<< overloads for basic_stacktrace and
stacktrace_entry probably don't work right for wide strings. They are
also defined in terms of to_string, but wide streams will convert for
charT==wchar_t, but do so via ctype<>::widen which doesn't work for
variable length encodings. Thus, identifiers for functions in the stack
trace may get mangled. I guess I should file a new LWG issue for this
assuming there isn't one already.

Tom.

On 11/29/22 3:40 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a telecon on Wednesday, November 30th, at 19:30 UTC
> (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20221130T193000&p1=1440&p2=tz_pst&p3=tz_mst&p4=tz_cst&p5=tz_est&p6=tz_cet>).
>
> *This message will also serve as your friendly reminder that this
> meeting is taking place tomorrow. **I'm sorry for publishing an agenda
> so very late. *
>
> *For participants in the USA, please note that daylight savings time
> ended 2022-11-06, so this telecon will start one hour earlier than our
> last telecon.*
>
> The agenda follows. We won't get through all of these. These are all
> of the NB comments we have left to address. Whatever we don't get to
> in this meeting will be scheduled for the December 14th meeting.
>
> * P2713R0: Escaping improvements in std::format
> <https://wg21.link/p2713r0>
> o US 38-098 22.14.6.4p1 [format.string.escaped] Escaping for
> debugging and logging
> <https://github.com/cplusplus/nbballot/issues/515>
> o FR 005-134 22.14.6.4 [format.string.escaped] Aggressive
> escaping <https://github.com/cplusplus/nbballot/issues/408>
> * P2693R0: Formatting thread::id and stacktrace
> <https://wg21.link/p2693r0>
> o FR-008-011 22.14 [format] Support formatting of thread::id
> <https://github.com/cplusplus/nbballot/issues/410>
> * FR-010-133 [Bibliography] Unify references to Unicode
> <https://github.com/cplusplus/nbballot/issues/412> and
> FR-021-013 5.3p5.2 [lex.charset] Codepoint names in identifiers
> <https://github.com/cplusplus/nbballot/issues/423>
> * P2675R0: LWG3780: The Paper (format's width estimation is too
> approximate and not forward compatible) <https://wg21.link/p2675r0>
> o LWG #3780: format's width estimation is too approximate and
> not forward compatible <https://cplusplus.github.io/LWG/issue3780>
> o FR-007-012 22.14.2.2 [format.string.std] codepoints with width
> 2 <https://github.com/cplusplus/nbballot/issues/409>
> * FR-020-014 5.3 [lex.charset] Replace "translation character set"
> by "Unicode" <https://github.com/cplusplus/nbballot/issues/422>
>
> P2713R0 <https://wg21.link/p2713r0> (Escaping improvements in
> std::format) implements the SG16 proposed resolutions for US 38-098
> <https://github.com/cplusplus/nbballot/issues/515> (see the 2022-10-19
> SG16 meeting summary
> <https://github.com/sg16-unicode/sg16-meetings#october-19th-2022>) and
> FR 005-134 <https://github.com/cplusplus/nbballot/issues/408> (see the
> 2022-11-02 SG16 meeting summary
> <https://github.com/sg16-unicode/sg16-meetings#november-2nd-2022>).
> We'll review the wording and then poll forwarding to LEWG as the
> resolution of the two NB comments.
>
> Candidate Poll 1: P2713R0: Forward to LEWG as the recommended
> resolution of US 38-098 and FR 005-134 [amended to ...].
>
> P2693R0 <https://wg21.link/p2693r0> (Formatting thread::id and
> stacktrace) is intended to resolve FR-008-011
> <https://github.com/cplusplus/nbballot/issues/410>. I did not
> initially tag this NB comment as needing SG16 review, but Bryce
> requested that SG16 take a look, specifically with regard to narrow vs
> wide formatting. Bryce has indicated this paper will need to be
> approved soon in order for it to appear in the electronic polling that
> will be conducted in January.
>
> Candidate Poll 2: P2693R0: Forward to LEWG as the recommended
> resolution of FR-008-011 [amended to ...].
>
> FR-010-133 <https://github.com/cplusplus/nbballot/issues/412> and
> FR-021-013 <https://github.com/cplusplus/nbballot/issues/423> were
> discussed during the 2022-11-02 SG16 meeting
> <https://github.com/sg16-unicode/sg16-meetings#november-2nd-2022> and
> concluded with a recommendation to discuss with the project editor the
> possibility of preferring the Unicode Standard over ISO/IEC 10646
> within the C++ standard. The project editor approved this direction
> and we can now move forward with drafting wording changes. This will
> require a paper produced in short order if it is to be accepted for C++23.
>
> P2675R0 <https://wg21.link/p2675r0> (LWG3780: The Paper (format's
> width estimation is too approximate and not forward compatible)) is
> intended to resolve LWG #3780
> <https://cplusplus.github.io/LWG/issue3780> and FR-007-012
> <https://github.com/cplusplus/nbballot/issues/409>. It seeks to
> replace the explicit list of code point ranges in
> [format.string.std]p12 <https://eel.is/c++draft/format.string.std#12>
> with wording that derives substantially the same set of code points
> using Unicode database properties.
>
> Candidate Poll 3.1: P2675R0: Forward to LEWG as the recommended
> resolution of FR-007-012 [amended to ...].
> Candidate Poll 3.2: P2675R0: Forward to LEWG for C++26 [amended to
> ...].
> Candidate Poll 3.3: Recommend to LEWG that FR-007-012 be rejected.
>
> FR-020-014 <https://github.com/cplusplus/nbballot/issues/422> raises
> concerns that were discussed as part of the reviews of P2314
> <https://wg21.link/p2314> and P2297 <https://wg21.link/p2297> during
> the 2021-03-24 SG16 meeting
> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2021.md#march-24th-2021>.
> The comment does not appear to present new information. If we choose
> to accept, a paper will need to be quickly produced.
>
> Candidate poll 4.1: Recommend to CWG that FR-020-014 be accepted.
> Candidate poll 4.2: Recommend to CWG that FR-020-014 be rejected.
>
> Tom.
>
>