My notes for this meeting are available on the (✨NEW!✨) WG21 wiki here
<https://wiki.isocpp.org/2026_Telecons:SG16Teleconference2026-03-11>.

The P3412 GH issue <https://github.com/cplusplus/papers/issues/2083> and
the P3951 GH issue <https://github.com/cplusplus/papers/issues/2602>
have been updated to record the poll that was taken and to note that
SG16 has not completed its review of these proposals.

This was my last time acting as SG16 chair for an SG16 meeting. I don't
expect further review of these papers to be disrupted by the change in
chairs and will assist Steve, at his request, with any scheduling,
preparation, or other planning for further review.

Tom.

On 3/10/26 4:11 PM, Tom Honermann via SG16 wrote:
>
> 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.
>
>