For P3412, I think it might be a good idea to make the standard `__FORMAT__` constexpr directly even though `std::format` is not constexpr yet, since it's already allowed in C++23 (by P2448 Relaxing some constexpr restrictions). f-string could be in constant context immediately if `std::format` becomes constexpr.

Liang Jiaming



From: Tom Honermann via SG16 <sg16_at_[hidden]>
Date: 2025-02-26 01:50:11
To: SG16 <sg16_at_[hidden]>,Tiago Freire <cpp_at_[hidden]>,Bengt Gustafsson <bengt.gustafsson_at_[hidden]>,Victor Zverovich <victor.zverovich_at_[hidden]>
Cc: Tom Honermann <tom_at_[hidden]>
Subject: [isocpp-sg16] Agenda for the 2025-02-26 SG16 meeting
SG16 will hold a meeting tomorrow, Wednesday, February 26th, at 19:30 UTC (timezone conversion).
If you need a .ics file to import into your calendar, you can download it here.
The agenda follows.
P3263R0: Encoding annotated char. P3412R1: String interpolation.Each paper will be allocated 45 minutes, including time for polls. If either paper requires more discussion time, then the authors will be invited back for further discussion in a follow up meeting. Neither proposal includes proposed wording, so we won't poll to forward either of them at this point.

P3263R0 comes to us courtesy of a new WG21 contributor, Tiago Freire. The paper seeks to enable programmers to declare user-defined text encoding tags and proposes a class template, std::char_enc_t, intended to be used to define code unit types for such encodings. An example use might look like this.
struct iso8859_1 : std::text_encoding {
   using char_t = unsigned char;
 };
 using char_iso8859_1 = std::char_enc_t<iso8859_1>;



The paper acknowledges and discusses the need for character and string literal support, but does not propose a solution (a future revision could). The intent is for these code unit types to be usable with std::basic_string and std::basic_string_view, but doesn't discuss integration with std::char_traits; a future revision would have to address that. For this discussion, we'll focus on motivation for user-declared encodings, interaction with P1885 (Naming Text Encodings to Demystify Them) which is already in C++26, and the minimal set of features required for programmers to make use of non-standard (from the C++ perspective) character encodings. Note that the std::text_encoding type proposed by this paper is not the std::text_encoding type adopted with P1885.
P3412R1 is offered by Bengt Gustafsson and Victor Zverovich and has already been reviewed by EWGI in Hagenberg; see here for EWGI notes. The paper proposes a string interpolation feature similar to Python's f-strings in which format field arguments can be written directly in the field. For example, instead of this:

std::string s = std::format("{:#06}", 42);
a programmer could write:
std::string s = f"{42:#06}";

The functionality is proposed as a preprocessor feature, at least in part, so that macros can be used in field expressions. The proposed f-string support is limited to use with ordinary and wide string literals; there is no support for UTF literals due to the lack of std::format support for the charN_t types. Considerations for SG16 include, but are not limited to, phases of translation, how string literal concatenation works (see section 13), nested string literals (see section 7.4), and whatever else you fine folks come up with.

Tom.