SG16 will hold a meeting *tomorrow*, Wednesday, March 11th, at 19:30 UTC
(timezone conversion
<https://www.timeanddate.com/worldclock/converter.html?iso=20260311T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cet>).

*Note that daylight savings time has started in North America, so this
meeting will start one hour later relative to the local time of our
previous meeting. There is no local time difference for those attending
from Europe.*

The agenda is:

  * P3412R3: String interpolation <https://wg21.link/p3412r3>.
  * D3951R1: String Interpolation with Template Strings
    <https://isocpp.org/files/papers/D3951R1.html>.

We began review of these proposals during the 2026-02-25 SG16 meeting
<https://wiki.isocpp.org/2026_Telecons:SG16Teleconference2026-02-25>,
but did not conclude discussion (we reviewed an earlier revision of
P3412R1 <https://wg21.link/p3412r1> during the 2025-02-26 SG16 meeting
<https://wiki.isocpp.org/2025_Telecons:SG16Teleconference2025-02-26> a
year ago). D3951R1 remains a draft revision, but was updated since our
last meeting to include support for UDLs; see section 3.10, "Support for
User-Defined Literals"
<https://isocpp.org/files/papers/D3951R1.html#support-for-user-defined-literals>.

Discussion in our last meeting suggested an emerging preference for the
lambda-like synthesis of an unnamed type model proposed by D3951R1 over
the __format__ mechanism of P3412R3. The representation of interpolated
strings is not a core SG16 concern, but it is relevant to other concerns
that we should be expected to provide guidance on. For example, whether
the selected model should be amenable to support for other formatting
facilities such as printf() or logging frameworks. Both proposals
discuss support for printf() via translation of a std::format-like
/format-specifier/ field, but other options are possible. For example,
the /format specifier/ could allow the specifiers to be context
dependent; e.g., std::printf(f"{name:%s}\n"). The details of how such
support might be provided are not so important right now, but it would
be helpful to provide direction on whether these proposals should be
extensible to printf() and other formatting facilities. Candidate polls:

  * Poll: Interpolated strings should be usable as the format argument
    to std::printf().
  * Poll: Interpolated strings should be consumable by arbitrary
    formatting facilities.

Full support for std::format(), std::print(), and std::printf() requires
support for char and the L (wchar_t) encoding prefix. It would be
helpful to establish guidance for support of the other encoding prefixes
and character types. Candidate polls:

  * Poll: The u8 (char8_t) encoding prefix should be supported.
  * Poll: The u (char16_t) encoding prefix should be supported.
  * Poll: The U (char32_t) encoding prefix should be supported.

Previous discussion has concerned lexing of interpolated strings, but we
haven't established positions on how alternate tokens, digraphs, UCNs,
escape sequences, and UDLs should be handled, particularly with regard
to support for raw-string literals. Consider
fR"xxx({foo(*u8'\t'*)})xxx". Is the expression well-formed because \t
denotes the tab character or is it ill-formed because multicharacter
literals cannot have an encoding prefix? If the latter, can string
literal concatenation be used to avoid the problem? e.g.,
fR"xxx({foo()xxx" *"u8'\t'"* R"xxx()})xxx"? If so, does concatenation
within an extraction field create implementation challenges? Candidate
polls:

  * Poll: Lexing of interpolated strings should scan for characters
    within extraction fields (not tokens; e.g., :: is two colon
    characters, not the scope resolution operator).
  * Poll: Extraction fields may span concatenated string literals (e.g.,
    f"{" "name" "}").
  * Poll: Alternate tokens and digraphs behave the same as their primary
    token when present in an extraction field (but not in the literal
    portions of the interpolated string).
  * Poll: UCNs may not designate members of the basic character set when
    present in an extraction field (but may in the literal portions of
    the (non-raw) interpolated string or in a nested literal).
  * Poll: Escape sequences (simple, numeric, and conditional) are not
    processed as escape sequences when present in an extraction field
    (e.g., they are initially treated as in raw string literals, but may
    act as an escape sequence in a nested literal).

Tom.