Thank you, Tom, for your leadership during your tenure as chair.

-- HT

On Sat, Mar 14, 2026 at 10:34 PM Tom Honermann via SG16 <
sg16_at_[hidden]> wrote:

> 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.
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
> Link to this post: http://lists.isocpp.org/sg16/2026/03/4699.php
>