Date: Tue, 25 Feb 2025 12:50:11 -0500
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.
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.
Received on 2025-02-25 17:50:15