On Wed, Feb 25, 2026, 20:31 Tom Honermann via SG16 <sg16_at_[hidden]>
wrote:

> While re-reading the papers today, I encountered a couple of questions
> related to lexing of interpolated literals and handling of digraphs and
> UCNs. If time permits today, we can discuss these examples. I'm using the
> syntax from P3412R3 below, but I think the questions apply to P2951R0 as
> well.
>
> P3412R3 section 7.1 prompted me to think of these lambda examples
> concerning lexical scanning for ',' and ':'. Note that angle brackets are
> not used for bracket matching. These might be worth adding as examples.
>
> - f"{[]<int,int>{}}" // lambda must be enclosed in
> parenthesis.
> - f"{[] post (r:r>0) { return 1; }}" // lambda must be enclosed in
> parenthesis.
>
> It makes sense for digraphs to not be recognized as part of an f-literal;
> that is consistent with string literals. Within string literals, digraphs
> aren't needed because UCNs can be used to specify characters that are in
> the basic character set but not necessarily available in the input source
> file encoding. Normally, UCNs are not permitted to match members of the
> basic character set in language syntax. What about in extraction fields?
> Should the following be well-formed?
>
> - f"The answer is {boolVar ? 17 \u003A 42}"; // U+003A is ':'
>
> There appears to be a tension with regard to lexical scanning of
> f-literals and parsing of extraction fields. Can macros allow for use of
> digraphs and UCNs in extraction fields? Should these be well-formed?
>
> - #define COLON :
> f"The answer is {boolVar ? 17 COLON 42}";
> - #define LEFT_SQUARE_BRACKET <:
> #define RIGHT_SQUARE_BRACKET :>
> f"The size is {sizeof int LEFT_SQUARE_BRACKET 42
> RIGHT_SQUARE_BRACKET}";
>
> Tom.
>
When parsing an embedded expression, they should be parsed as expressions
(digraphs, no ASCII ucn etc). when parsing the string literal outside of
embedded expression fragments, the rules of string literals should apply
(no digraphs, etc).

anything else would be a great implementation burden and weird form a user
standpoint.

Whether macro expands seems like an lewg question (if we follow the model
of these being nested expressions, then macro expansion should happen for
consistency but it depends when an implementation can actually parse these
fragments)


On 2/22/26 11:15 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting Wednesday, February 25th, at 19:30 UTC (timezone
> conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20260225T193000&p1=1440&p2=tz_pst&p3=tz_mst&p4=tz_cst&p5=tz_est&p6=tz_cet>
> ).
>
> The agenda is:
>
> - P3412R3: String interpolation <https://wg21.link/p3412r3>.
> - P3951R0: String Interpolation with Template Strings
> <https://wg21.link/p3951r0>.
>
> SG16 previously reviewed *P3412R1 <https://wg21.link/p3412r1>* during the 2025-02-26
> SG16 meeting
> <https://wiki.isocpp.org/2025_Telecons:SG16Teleconference2025-02-26>.
> Concerns raised then included interaction with the preprocessor, the phases
> of translation, handling of escape sequences, standalone usability, and
> integration with std::format(). Bengt will present a brief overview of
> the proposal and the updates in the new revisions intended to address prior
> SG16 review feedback.
>
> *P3951R0* is a new paper courtesy of Barry that offers an alternative
> perspective on string interpolation that makes different tradeoffs relative
> to P3412R3.
>
> Please try to set aside time to read both of these papers before the
> meeting as there are many details to consider. Spend some time considering
> possible future use cases (from an SG16 perspective) and the ability for
> each design to evolve to satisfy them.
>
> I don't expect discussion on these papers to conclude at this meeting.
> Plan for 30 minutes of presentation and clarifying questions for each
> paper. We'll then proceed with general discussion. Ideally, discussion
> would lead authors towards a unified/merged design or a determination that
> one proposal or the other is objectively better suited to desired and
> anticipated uses. If consensus for a single design fails to emerge, then
> we'll focus on understanding the points of contention with a goal of
> ensuring LEWG is well informed of the relevant tradeoffs.
>
> 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/02/4679.php
>