Date: Thu, 18 Apr 2024 21:37:35 -0400
> On Apr 18, 2024, at 7:21 PM, Tom Honermann <tom_at_[hidden]> wrote:
>
> SG16 will hold a meeting on Wednesday, April 24th, at 19:30 UTC (timezone conversion <https://www.timeanddate.com/worldclock/converter.html?iso=20240424T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>
> The agenda follows.
>
> P1953R0: Unicode Identifiers And Reflection <https://wg21.link/p1953r0>
> P2996R2: Reflection for C++26 <http://wg21.link/p2996r2>
> Though Corentin bestowed P1953R0 upon us quite some time ago, we never formally reviewed it. It had an honorable mention during the 2020-02-26 SG16 meeting <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2020.md#february-26th-2020> in which Corentin declared that progress on it was blocked by needing to advance P1949 (C++ Identifier Syntax using Unicode Standard Annex 31) <https://wg21.link/p1949> and by further progress on the reflection proposal. Time passed and, despite the high priority interrupt that consumed the world for most of that time, progress was made. P1949R7 was adopted for C++23 and P2996 was forwarded by SG7 during the Kona 2023 meeting <https://wiki.edg.com/bin/view/Wg21kona2023/SG7> with very strong consensus! 🎉 🥳 🪅 🪩
>
> The primary review focus will be on how identifiers, particularly those that include characters not in the basic literal character set <http://eel.is/c++draft/lex.charset#7>, are encoded in the string returned by the name_of(), qualified_name_of(), and display_name_of() members of the std::meta namespace. P2996R2 states, in section 4.4.6, "name_of, display_name_of, source_location_of":
>
> ... The contents of the string_view consist of characters of the basic source character set only (an implementation can map other characters using universal character names).
>
Right. You mentioned in Tokyo that that doesn’t work. Can you elaborate what the technical hickup is?
> As far as I can tell, P2996R2 does not specify any functions that consume strings in the returned encoding.
>
As Peter mentioned, the `define_class` metafunction needs a way to specify names. You’re correct that we haven’t worked out the wording for that yet. (I.e., in P2996R2 it’s currently only apparent in the introductory examples and in section 4.4.15, which describes the feature informally).
> Assuming there are no plans to change that, these names are strictly informational; someone please correct me if I am mistaken about that. The proposed design as indicated in the quoted text above and in the proposed wording in section 5.2.3 [meta.reflection.names], "Reflection names and locations", is that the names are implementation-defined and thus non-portable. There are a number of options that we can consider, some of which are enumerated in P1953R0.
>
> When the ordinary literal encoding is a UTF encoding, there is presumably no need to restrict the returned names to characters from the basic literal character set.
> Calls to these functions can be made ill-formed (these functions are declared consteval) when the ordinary literal encoding is unable to represent one or more characters in the name.
> Variations of name_of() et al. could be provided that return names in one or more UTF encodings to ensure the availability of non-escaped non-lossy names.
> Following the adoption of P2713R1 (Escaping improvements in std::format) <https://wg21.link/p2713r1> for C++23, we have a specified escape format that could be adapted to provide portable names; see [format.string.escaped] <http://eel.is/c++draft/format.string.escaped>.
> Assuming we reach a conclusion regarding representation of names, we'll then move on to any other SG16 related topics that concern reflection. I'm not aware of any others in the context of P2996R2; please reply in advance of the meeting with any additional topics we should discuss.
I’m not aware of other reflection topics that are SG16 related.
Daveed
>
> SG16 will hold a meeting on Wednesday, April 24th, at 19:30 UTC (timezone conversion <https://www.timeanddate.com/worldclock/converter.html?iso=20240424T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>
> The agenda follows.
>
> P1953R0: Unicode Identifiers And Reflection <https://wg21.link/p1953r0>
> P2996R2: Reflection for C++26 <http://wg21.link/p2996r2>
> Though Corentin bestowed P1953R0 upon us quite some time ago, we never formally reviewed it. It had an honorable mention during the 2020-02-26 SG16 meeting <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2020.md#february-26th-2020> in which Corentin declared that progress on it was blocked by needing to advance P1949 (C++ Identifier Syntax using Unicode Standard Annex 31) <https://wg21.link/p1949> and by further progress on the reflection proposal. Time passed and, despite the high priority interrupt that consumed the world for most of that time, progress was made. P1949R7 was adopted for C++23 and P2996 was forwarded by SG7 during the Kona 2023 meeting <https://wiki.edg.com/bin/view/Wg21kona2023/SG7> with very strong consensus! 🎉 🥳 🪅 🪩
>
> The primary review focus will be on how identifiers, particularly those that include characters not in the basic literal character set <http://eel.is/c++draft/lex.charset#7>, are encoded in the string returned by the name_of(), qualified_name_of(), and display_name_of() members of the std::meta namespace. P2996R2 states, in section 4.4.6, "name_of, display_name_of, source_location_of":
>
> ... The contents of the string_view consist of characters of the basic source character set only (an implementation can map other characters using universal character names).
>
Right. You mentioned in Tokyo that that doesn’t work. Can you elaborate what the technical hickup is?
> As far as I can tell, P2996R2 does not specify any functions that consume strings in the returned encoding.
>
As Peter mentioned, the `define_class` metafunction needs a way to specify names. You’re correct that we haven’t worked out the wording for that yet. (I.e., in P2996R2 it’s currently only apparent in the introductory examples and in section 4.4.15, which describes the feature informally).
> Assuming there are no plans to change that, these names are strictly informational; someone please correct me if I am mistaken about that. The proposed design as indicated in the quoted text above and in the proposed wording in section 5.2.3 [meta.reflection.names], "Reflection names and locations", is that the names are implementation-defined and thus non-portable. There are a number of options that we can consider, some of which are enumerated in P1953R0.
>
> When the ordinary literal encoding is a UTF encoding, there is presumably no need to restrict the returned names to characters from the basic literal character set.
> Calls to these functions can be made ill-formed (these functions are declared consteval) when the ordinary literal encoding is unable to represent one or more characters in the name.
> Variations of name_of() et al. could be provided that return names in one or more UTF encodings to ensure the availability of non-escaped non-lossy names.
> Following the adoption of P2713R1 (Escaping improvements in std::format) <https://wg21.link/p2713r1> for C++23, we have a specified escape format that could be adapted to provide portable names; see [format.string.escaped] <http://eel.is/c++draft/format.string.escaped>.
> Assuming we reach a conclusion regarding representation of names, we'll then move on to any other SG16 related topics that concern reflection. I'm not aware of any others in the context of P2996R2; please reply in advance of the meeting with any additional topics we should discuss.
I’m not aware of other reflection topics that are SG16 related.
Daveed
Received on 2024-04-19 01:37:49