This meeting is starting now.

Tom.

On 2/25/25 12:50 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting *tomorrow*, Wednesday, February 26th, at
> 19:30 UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20250226T193000&p1=1440&p2=tz_pst&p3=tz_mst&p4=tz_cst&p5=tz_est&p6=tz_cet>).
>
> If you need a .ics file to import into your calendar, you can download
> it here
> <https://documents.isocpp.org/remote.php/dav/calendars/tahonermann/wg21-telecons_shared_by_hfinkel/7124BD17-1DF0-42A0-8CF2-4FB4D9F5FE03.ics?export>.
>
> The agenda follows.
>
> * P3263R0: Encoding annotated char <https://wg21.link/p3263r0>.
> * P3412R1: String interpolation <https://wg21.link/p3412r1>.
>
> 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) <https://wg21.link/p1885> 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
> <https://wiki.edg.com/bin/view/Wg21hagenberg2025/EWGIP3412R1> for EWGI
> notes. The paper proposes a string interpolation feature similar to
> Python's f-strings
> <https://docs.python.org/3/reference/lexical_analysis.html#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 char/N/_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.
>
>