Date: Wed, 14 Aug 2024 18:22:49 -0000
Hey Corentin,
You're right, and that's actually what the authors had originally discussed, how I implemented it, and what we meant to write. Removing the 'u8'-prefix now; thanks for the catch.
Best,
---Dan
From: corentinjabot_at_[hidden] At: 08/14/24 14:05:04 UTC-4:00To: sg16_at_[hidden]
Cc: Dan Katz (BLOOMBERG/ 919 3RD A ) , daveed_at_[hidden], sinbal2l_at_[hidden], tom_at_[hidden]
Subject: Re: [isocpp-sg16] Agenda for the 2024-08-14 SG16 meeting
On Wed, Aug 14, 2024 at 5:17 PM Tom Honermann via SG16 <sg16_at_[hidden]> wrote:
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).
The agenda follows.
*
*D2996R5: Reflection for C++26.
*
*P2319R0: Prevent path presentation problems.
*
We previously reviewed P2996R2 during the 2024-04-24 and 2024-05-08 SG16 meetings. We also discussed some of the design options for reflecting names during the joint LEWG/SG16 review of P2996R4 in St. Louis (see minutes here; 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)
2)The name_of() and qualified_name_of() functions have been removed (along with their u8 prefixed variants).
3)The display_name_of() function has been renamed to display_string_of().
4)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.
There is no reason for define_static_string not to be an overloaded function supporting both u8 and char strings.
u8 prefixes are only "necessary" for cases when the return type cannot be deduced from the parameter.
As an aside, i would much rather make std::string allocation not transient than introducing these ""hacks"" that are unlikely to be useful in the long term
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.
--
SG16 mailing list
SG16_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/sg16
You're right, and that's actually what the authors had originally discussed, how I implemented it, and what we meant to write. Removing the 'u8'-prefix now; thanks for the catch.
Best,
---Dan
From: corentinjabot_at_[hidden] At: 08/14/24 14:05:04 UTC-4:00To: sg16_at_[hidden]
Cc: Dan Katz (BLOOMBERG/ 919 3RD A ) , daveed_at_[hidden], sinbal2l_at_[hidden], tom_at_[hidden]
Subject: Re: [isocpp-sg16] Agenda for the 2024-08-14 SG16 meeting
On Wed, Aug 14, 2024 at 5:17 PM Tom Honermann via SG16 <sg16_at_[hidden]> wrote:
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).
The agenda follows.
*
*D2996R5: Reflection for C++26.
*
*P2319R0: Prevent path presentation problems.
*
We previously reviewed P2996R2 during the 2024-04-24 and 2024-05-08 SG16 meetings. We also discussed some of the design options for reflecting names during the joint LEWG/SG16 review of P2996R4 in St. Louis (see minutes here; 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)
2)The name_of() and qualified_name_of() functions have been removed (along with their u8 prefixed variants).
3)The display_name_of() function has been renamed to display_string_of().
4)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.
There is no reason for define_static_string not to be an overloaded function supporting both u8 and char strings.
u8 prefixes are only "necessary" for cases when the return type cannot be deduced from the parameter.
As an aside, i would much rather make std::string allocation not transient than introducing these ""hacks"" that are unlikely to be useful in the long term
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.
--
SG16 mailing list
SG16_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/sg16
Received on 2024-08-14 18:22:50