This meeting is starting now. We're a bit low on quorum at the moment,
so please join in if you can!

Tom.

On 5/7/24 3:04 PM, Tom Honermann via SG16 wrote:
>
> 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.
>>
>>
>