P3258 R0 Formatting charN_t

[wg21bot]

P3258R0 Formatting charN_t (Corentin Jabot)

[jensmaurer]

This adds a definition to the core language and thus needs eventual CWG (but not EWG) review.

[tahonermann]

SG16 reviewed P3258R0 during its 2024-11-06 meeting. The following polls were taken:

• Poll 1: It is more important to avoid implicit loss of information during transcoding operations than to provide support for formatting charN_t in the standard library.

  • Attendees: 7	SF	F	N	A	SA
    1	3	1	1	1

  • Weak consensus in favor.
• Poll 2: Encourage more work on P3258R0, particularly with regard to handling of transcoding failures.

  • Attendees: 6	SF	F	N	A	SA
    3	0	0	2	1

  • No consensus.
• Poll 3: Encourage work on support for std::format and std::print with charN_t format strings.

  • Attendees: 6	SF	F	N	A	SA
    3	2	1	0	0

  • Consensus in favor.

SG16 was split on support for this proposal vs pursuing only support for charN_t specializations of std::format() and friends (in some future proposal). With respect to formatting values of charN_t types, there are several complementary designs that can support doing so.

1. Allow the existing char and/or wchar_t specializations of std::format() and friends to format values of charN_t type; the solution proposed in P3258.
2. Introduce new charN_t specializations of std::format() and friends and allow them to format values of charN_t type, but not values of char or wchar_t type; no existing proposal.

The primary concern raised for the first design, this proposal, is that transcoding the charN_t values to the encoding of char or wchar_t may result in information loss; unrepresentable characters might be substituted with a replacement character (e.g., U+FFFD REPLACEMENT CHARACTER) or escape mechanism (e.g., \u{1234}). Some SG16 members find this to be acceptable; others feel this is contrary to the original intent of std::format() and find the potential information loss unacceptable, even with a graceful degradation approach.

The second design requires solving locale concerns (e.g., introducing charN_t specializations of std::locale facets) or eschewing support for localized formatting (e.g., the L modifier that can be used with many standard formatters).

The implicit third design option is the status quo in which programmers are required to perform transcoding operations on their own.

I'm not convinced that SG16 has exhausted discussion on this proposal, so I'm going to retain the SG16 label for now.