Date: Tue, 7 May 2024 19:28:54 -0000
Hey Tom,
I'll be attending (as a co-author). I'm a bit behind the current SG16-relevant discussions, but I'll try to get up to speed before the meeting.
Best,
---Dan
From: tom_at_[hidden] At: 05/07/24 15:04:22 UTC-4:00To: Dan Katz (BLOOMBERG/ 919 3RD A ) , sg16_at_[hidden], daveed_at_[hidden], faisalv_at_[hidden], andrew.n.sutton_at_[hidden], barry.revzin_at_[hidden], pdimov_at_[hidden], wcc_at_[hidden]
Subject: Re: [SG16] Agenda for the 2024-05-08 SG16 meeting
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).
The agenda follows.
*
*D3258R0: Formatting of charN_t.
*
*P2996R2: Reflection for C++26.
*
D3258R0 was hastily produced by Corentin following the review of P2996R2 during the 2024-04-24 SG16 meeting 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 as well as the ensuing "Follow up on SG16 review of P2996R2" discussion on the SG16 mailing list prior to the meeting.
1)
2)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)
2)Names will be produced and consumed in both the ordinary literal encoding via type char and UTF-8 via type char8_t.
3)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.
4)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.
3)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).
4)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) 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.
I'll be attending (as a co-author). I'm a bit behind the current SG16-relevant discussions, but I'll try to get up to speed before the meeting.
Best,
---Dan
From: tom_at_[hidden] At: 05/07/24 15:04:22 UTC-4:00To: Dan Katz (BLOOMBERG/ 919 3RD A ) , sg16_at_[hidden], daveed_at_[hidden], faisalv_at_[hidden], andrew.n.sutton_at_[hidden], barry.revzin_at_[hidden], pdimov_at_[hidden], wcc_at_[hidden]
Subject: Re: [SG16] Agenda for the 2024-05-08 SG16 meeting
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).
The agenda follows.
*
*D3258R0: Formatting of charN_t.
*
*P2996R2: Reflection for C++26.
*
D3258R0 was hastily produced by Corentin following the review of P2996R2 during the 2024-04-24 SG16 meeting 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 as well as the ensuing "Follow up on SG16 review of P2996R2" discussion on the SG16 mailing list prior to the meeting.
1)
2)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)
2)Names will be produced and consumed in both the ordinary literal encoding via type char and UTF-8 via type char8_t.
3)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.
4)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.
3)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).
4)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) 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.
Received on 2024-05-07 19:28:55