On Tue, Mar 10, 2026 at 7:24 PM Hubert Tong <
hubert.reinterpretcast_at_[hidden]> wrote:

> On Tue, Mar 10, 2026 at 4:11 PM Tom Honermann via SG16 <
> 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().
>>
>> 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).
>
>>
>>
>> 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 believe we got presentations, but I don't recall the group adopting a
> lexing approach.
>
>> 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).
>>
>> 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.
> 2. The extraction token consists of three pp-tokens: " ", name, and "
> ".
>
> Typo: s/extraction token/extraction field/


> 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)"
>

Typo:
Last line should read
)abcdef"


>
> I would be okay with
> fR"abcdef(
> abcdef{R"abcdef()abcdef"}abcdef
> abcdef)"
>

Same typo.