On 8/23/23 12:10 PM, Victor Zverovich via SG16 wrote:
> Yes, that's intentional. I think it's better to make all format
> specifiers behave consistently across platforms and within the same
> type rather than try to fully mimic printf. Compared to other
> differences from printf, this one is very minor.

Thank you for the confirmation. I think it would be useful for the paper
to address this; to note the deviation and explain the motivation for it.

Tom.

>
> - Victor
>
> On Wed, Aug 23, 2023 at 8:56 AM Tom Honermann via SG16
> <sg16_at_[hidden]> wrote:
>
> On 8/23/23 11:40 AM, Tom Honermann via SG16 wrote:
>>
>> SG16 will hold a telecon on Wednesday, August 23rd, at 19:30 UTC
>> (timezone conversion
>> <https://www.timeanddate.com/worldclock/converter.html?iso=20230823T193000&p1=1440&p2=tz_pt&p3=tz_mt&p4=tz_ct&p5=tz_et&p6=tz_cest>).
>>
>> That is *today*, *in about 4 hours*. Obviously, I'm still
>> struggling to keep up with all the things.
>>
>> The agenda follows.
>>
>> * P2909R0: Dude, where’s my char? <https://wg21.link/p2909r0>
>> * P2728R6: Unicode in the Library, Part 1: UTF Transcoding
>> <https://wg21.link/p2728r6>
>>
>> P2902R0 is a new paper from Victor that seeks to establish
>> portable behavior for formatting of objects of type char
>> regardless of the implementation-defined signedness of char.
>>
> Victor, the proposed wording changes the behavior for all of the
> b, B, d, o, x, and X type options. That would improve
> compatibility with printf() in most cases, but would create a
> divergence for the d type option. Is that intentional?
> https://godbolt.org/z/G8dGhrG66.
>
> Tom.
>
>> P2728 was last discussed during the 2023-05-10 SG16 telecon
>> <https://github.com/sg16-unicode/sg16-meetings#may-10th-2023>. I
>> have continued to hear feedback that the motivation for the
>> proposal, as presented in the paper, is lacking. I'd like to
>> focus on giving Zach specific, concrete, and clear direction
>> regarding how to improve the paper in this respect. Comments
>> should focus on what is perceived to be missing and what changes
>> would fill those gaps. Following that, I would like to focus on
>> error handling. The proposal includes a transcoding_error_handler
>> concept and a use_replacement_character class that models that
>> concept and that provides the default error handling behavior.
>> The error handler is specified to take a message passed as an
>> object of type std::string_view, but does not specify the
>> contents of the message. The error handler is constrained to
>> return a single value of type char32_t and is not given access to
>> the source text (except. possibly via the message, which is
>> always char-based). Is this sufficient? If not, what changes are
>> needed?
>>
>> Tom.
>>
>>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
>