Date: Wed, 14 Aug 2024 11:17:06 -0400
This is your friendly reminder that we are meeting *today*, in about 4
hours.
Tom.
On 8/12/24 11:39 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting on Wednesday, August 14th, at 19:30 UTC
> (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20240814T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>
> The agenda follows.
>
> * D2996R5: Reflection for C++26 <https://wg21.link/d2996r5>.
> * P2319R0: Prevent path presentation problems
> <https://wg21.link/p2319r0>.
>
> We previously reviewed P2996R2 <https://wg21.link/p2996r2> during the
> 2024-04-24
> <https://github.com/sg16-unicode/sg16-meetings#april-24th-2024> and
> 2024-05-08
> <https://github.com/sg16-unicode/sg16-meetings#may-8th-2024> SG16
> meetings. We also discussed some of the design options for reflecting
> names during the joint LEWG/SG16 review of P2996R4
> <https://wg21.link/p2996r4> in St. Louis (see minutes here
> <https://wiki.edg.com/bin/view/Wg21stlouis2024/P2996#Library-Evolution-2024-06-26>;
> search for "SG16" or "Second Afternoon Session"), but did not finish
> discussion of all topics. The reflection authors have continued
> iterating on the design and a D2996R5 draft is available. There have
> been some notable changes that are relevant for SG16:
>
> 1. The name_of() and qualified_name_of() functions have been removed
> (along with their u8 prefixed variants).
> 2. The display_name_of() function has been renamed to
> display_string_of().
> 3. New identifier_of(), operator_of(), and define_static_string()
> functions have been added (along with u8 prefixed variants for
> identifier_of() and define_static_string()).
>
> The new identifier_of() function follows previously provided SG16
> guidance; invocations are not constant expressions if the identifier
> to be returned is not representable in the ordinary literal encoding
> (invocations of u8identifier_of() never fail to be constant
> expressions due to issues of representation).
>
> The new define_static_string() (and u8define_static_string())
> functions have been added as a general interface to declare strings
> that will persist beyond a constant expression evaluation. These
> functions enable a string to be constructed during constant evaluation
> and then preserved for use as the backing storage of a
> std::string_view (or std::u8string_view) object at run-time.
>
> I have asked Dan and Daveed to provide a brief introduction of the
> changes. We'll discuss the changes and potentially poll approval of
> these design aspects.
>
> P2319R0 is a new paper courtesy of Victor that seeks to resolve some
> ambiguous encoding issues with std::filesystem::path. It proposes to
> deprecate and replace the existing string() member function with new
> display_string() and system_string() member functions with clear
> encoding specifications. Similar replacements are proposed for the
> existing generic_string() member function. Note that these ambiguous
> encoding issues are not present for the u8, u16, and u32 prefixed
> variants of these functions; we can discuss whether similar concerns
> are present for wstring() and generic_wstring(). We'll review the
> paper and potentially poll forwarding it.
>
> Tom.
>
>
hours.
Tom.
On 8/12/24 11:39 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting on Wednesday, August 14th, at 19:30 UTC
> (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20240814T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>
> The agenda follows.
>
> * D2996R5: Reflection for C++26 <https://wg21.link/d2996r5>.
> * P2319R0: Prevent path presentation problems
> <https://wg21.link/p2319r0>.
>
> We previously reviewed P2996R2 <https://wg21.link/p2996r2> during the
> 2024-04-24
> <https://github.com/sg16-unicode/sg16-meetings#april-24th-2024> and
> 2024-05-08
> <https://github.com/sg16-unicode/sg16-meetings#may-8th-2024> SG16
> meetings. We also discussed some of the design options for reflecting
> names during the joint LEWG/SG16 review of P2996R4
> <https://wg21.link/p2996r4> in St. Louis (see minutes here
> <https://wiki.edg.com/bin/view/Wg21stlouis2024/P2996#Library-Evolution-2024-06-26>;
> search for "SG16" or "Second Afternoon Session"), but did not finish
> discussion of all topics. The reflection authors have continued
> iterating on the design and a D2996R5 draft is available. There have
> been some notable changes that are relevant for SG16:
>
> 1. The name_of() and qualified_name_of() functions have been removed
> (along with their u8 prefixed variants).
> 2. The display_name_of() function has been renamed to
> display_string_of().
> 3. New identifier_of(), operator_of(), and define_static_string()
> functions have been added (along with u8 prefixed variants for
> identifier_of() and define_static_string()).
>
> The new identifier_of() function follows previously provided SG16
> guidance; invocations are not constant expressions if the identifier
> to be returned is not representable in the ordinary literal encoding
> (invocations of u8identifier_of() never fail to be constant
> expressions due to issues of representation).
>
> The new define_static_string() (and u8define_static_string())
> functions have been added as a general interface to declare strings
> that will persist beyond a constant expression evaluation. These
> functions enable a string to be constructed during constant evaluation
> and then preserved for use as the backing storage of a
> std::string_view (or std::u8string_view) object at run-time.
>
> I have asked Dan and Daveed to provide a brief introduction of the
> changes. We'll discuss the changes and potentially poll approval of
> these design aspects.
>
> P2319R0 is a new paper courtesy of Victor that seeks to resolve some
> ambiguous encoding issues with std::filesystem::path. It proposes to
> deprecate and replace the existing string() member function with new
> display_string() and system_string() member functions with clear
> encoding specifications. Similar replacements are proposed for the
> existing generic_string() member function. Note that these ambiguous
> encoding issues are not present for the u8, u16, and u32 prefixed
> variants of these functions; we can discuss whether similar concerns
> are present for wstring() and generic_wstring(). We'll review the
> paper and potentially poll forwarding it.
>
> Tom.
>
>
Received on 2024-08-14 15:17:10