This is your friendly reminder that this meeting is occurring tomorrow.

Daveed informed me that he will not be able to attend, but he blessed
further review in his absence. It would therefore be even more helpful
if other P2996 authors can attend.

Tom.

On 5/6/24 1:22 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting on Wednesday, May 8th, at 19:30 UTC (timezone
> conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20240508T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>
> The agenda follows.
>
> * D3258R0: Formatting of charN_t <https://wg21.link/d3258r0>.
> * P2996R2: Reflection for C++26 <http://wg21.link/p2996r2>.
>
> D3258R0 was hastily produced by Corentin following the review of
> P2996R2 during the 2024-04-24 SG16 meeting
> <https://github.com/sg16-unicode/sg16-meetings/#april-24th-2024> with
> the goal of providing a convenient solution for printing UTF-8 text
> held in char8_t-based storage. It proposes extending std::format() and
> std::print() to support formatting arguments of Unicode character type
> (characters and strings of char8_t, char16_t, or char32_t type). It
> does not propose a solution for iostreams. We won't poll this paper
> during this meeting for two reasons: 1) the paper is hot off the press
> and I don't expect everyone to have already read it and internalized
> all the implications, and 2) I'm going to limit discussion of it to
> the first half of the meeting so that we continue to make progress on
> P2996. The intent in discussing it, particularly with the P2996
> authors present, is to build a sense of whether it suffices to at
> least minimally address the printing requirements posed by the P2996
> authors; we may take a poll on that point.
>
> Our recent review of P2996R2 was constructive but not conclusive.
> We'll continue discussion with a goal of establishing consensus on the
> following points. Please review the meeting summary from the last
> review
> <https://github.com/sg16-unicode/sg16-meetings/#april-24th-2024> as
> well as the ensuing "Follow up on SG16 review of P2996R2" discussion
> on the SG16 mailing list
> <https://lists.isocpp.org/sg16/2024/04/index.php> prior to the meeting.
>
> 1. The character type(s) and encoding(s) used for names produced and
> consumed by reflection interfaces. My sense is that we're leaning
> in the following direction (not unanimously though):
> 1. Names will be produced and consumed in both the ordinary
> literal encoding via type char and UTF-8 via type char8_t.
> 2. Production of names that contain characters that are not
> representable in the ordinary literal encoding will produce a
> string that contains a UCN-like escape sequence for such
> characters.
> 3. Consumption of names in the ordinary literal encoding will
> accept a UCN-like escape sequence for characters not in the
> basic literal character set that may lack representation in
> the ordinary literal encoding.
> 2. The use of a distinct type for names (e.g., a type that stores
> names in an internal representation and exposes them via char and
> char8_t interfaces).
> 3. Unicode NFC requirements (see below).
>
> We briefly discussed Unicode normalization form C (NFC) last time.
> Following adoption of P1949R7 (C++ Identifier Syntax using Unicode
> Standard Annex 31) <https://wg21.link/p1949r7> as a DR for C++23,
> identifiers are required to be written in NFC. Conversion to the
> ordinary literal encoding could result in names that are not in NFC.
> It will presumably be necessary for P2996 to specify that, for
> round-trip purposes, conversion to the ordinary literal encoding will
> not perform character substitutions (e.g., UNC-like escape sequences
> will be generated instead). Likewise, it will be necessary to specify
> how names that do not conform to NFC will be handled by reflection
> interfaces that consume user provided names. Note that current
> compiler releases exhibit implementation divergence with respect to
> enforcement of the NFC requirement (https://godbolt.org/z/E35r1K7hE;
> gcc does diagnose, Clang and EDG do not, MSVC does not yet implement
> P1949R7).
>
> Finally, and as a separable issue that can be discussed at another
> time, I think we should discuss differentiating between names and
> identifiers in the reflection interfaces. This isn't an issue for
> data_member_spec() since data members are always identifiers (or are
> unnamed; that is another interesting case, but isn't an SG16 concern),
> but could be an issue for a hypothetical function_spec() or
> member_function_spec() interface used for named functions,
> constructors and destructors, overloaded operators, conversion
> operators, user-defined literals, etc.... Distinguishing between names
> and identifiers would avoid the need to parse, e.g., operator bool or
> ""_udl, when consuming names.
>
> Tom.
>
>