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.

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