On Tue, Nov 29, 2022 at 10:54 PM Tom Honermann via SG16 <
sg16_at_[hidden]> wrote:

> 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.
>

Yes, this is correct. There is no intent in our paper that format(L"",
stacktrace); should work. It's all preexisting.
You will notice that there is no formatter specialization proposed for wide
strings.

We (SG16) previously decided that the content of the stacktrace string is
implementation-defined and we could devise scenarios such that they would
involve multiple encodings within that string.
So what is proposed matches that. wide encodings cannot be supported as
immediately the question of "from what encoding do we convert" would have
to be answered,
and that would kind of force us to ask about the encoding of symbol names
in the binary, which we never talked about before.
We do not intend to ask, or answer these questions as part of this paper.

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>
> - US 38-098 22.14.6.4p1 [format.string.escaped] Escaping for
> debugging and logging
> <https://github.com/cplusplus/nbballot/issues/515>
> - 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>
> - 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>
> - LWG #3780: format's width estimation is too approximate and not
> forward compatible <https://cplusplus.github.io/LWG/issue3780>
> - 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.
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>