On 3/11/26 00:24, Hubert Tong via SG16 wrote:
> On Tue, Mar 10, 2026 at 4:11 PM Tom Honermann via SG16 <sg16_at_[hidden] <mailto:sg16_at_[hidden]>> 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.
>
> Thanks Tom for organizing.
>
> Candidate polls:
>
> * Poll: Interpolated strings should be usable as the format argument to std::printf().

I thought that was the motivation for this facility? Use std::printf(f"whatever{name}")
and be happy?
 
> During the discussion, is there anyone who will champion this? At a minimum, there needs to be recorded rationale; for example, to support limited runtime environments that have printf-like facilities.

> * Poll: Interpolated strings should be consumable by arbitrary formatting facilities.
>
> IMO, this poll is too vague as to the ergonomics of the "consumability".
>
> An additional candidate poll is:
> Poll: Interpolated strings should be usable in C-like C++ code in contexts suitable for pure C (if C were to have interpolated strings).

Good question. SG22 might have an opinion, too.

> 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.

I would like to point out that UCNs and escape sequences are interpreted "late"
inside string literals (see [lex.string} p10), i.e. when the string literal object
is initialized during execution (phase 7 for constant evaluation the earliest).

For me, that means anything that becomes individual pp-tokens due to unwrapping {blah}
stuff is subject to the "as in plain source code" rules, and anything that stays inside
a string literal after unwrapping is subject to the "string literal" rules for these
special things.
 
> I believe we got presentations, but I don't recall the group adopting a lexing approach.

I don't remember seeing nested string-literals being discussed in D3951R1, e.g.

f"{name + "abc"}"

(and this can nest arbitrarily deep using f"..." instead of "abc")

Or is this not supposed to be supported? P3412R3 strives to support this, I think.

> I would prefer to ask whether an interpolated string is "string first" (whose string value is then processed to identify extraction fields which may contain text that will be pp-tokenized) or a piecewise construct (where extraction fields contain pp-tokens).
> Especially for the second poll, the two models generate different, valid interpretations of
> f"{" "name" "}"
>
> 1. name is the sole pp-token in the extraction field.

This probably means we need to run another phase 4 after string concatenation
in phase 5, or somehow interleave these phases. Not insurmountable, just a
remark.

> I also have qualms about allowing extraction fields in raw strings without the involvement of the d-char-sequence.
> In particular, I am against having the "outer raw string" end later than the first instance of )abcdef" in the following:
> fR"abcdef(
> {R"abcdef()abcdef"}
> )abcdef"
>
> I would be okay with
> fR"abcdef(
> abcdef{R"abcdef()abcdef"}abcdef
> )abcdef"
(typos fixed in above quotes)

I'm not seeing the difference between those two cases.
There is a first )abcdef" in the second lines of each example,
so (arguably) that's where the fR string-literal ends.

Before interpolated raw string literals become a rathole
(for me, "interpolated raw" is an inherent contradiction),
I wouldn't mind excluding them for the first round of
this facility.

Jens