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).

As far as I can tell, P2996R2 does not specify any functions that
consume strings in the returned encoding. 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.

Tom.