This is your friendly reminder that this meeting is taking place tomorrow.

Tom.

On 4/18/24 7:21 PM, Tom Honermann via SG16 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).
>
> 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.
>
>