On 11/29/22 5:10 PM, Corentin Jabot wrote:
>
>
> 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.

Thank you. It wasn't obvious to me that support for wide characters is
not intended either in the proposal or in the existing wording for the
ostream inserters. I find it odd that the ostream inserter declarations
are specified for basic_ostream<charT, ...> but then specified such that
charT!=char renders the program ill-formed. Why don't the declarations
just require char? (I'm asking rhetorically).

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

Thanks, agreed, and I'm content with that.

Tom.

>
> 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.
>>
>>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>