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.

SG16 will hold a meeting Wednesday, February 25th, at 19:30 UTC (timezone conversion).

The agenda is:

• P3412R3: String interpolation.
• P3951R0: String Interpolation with Template Strings.

SG16 previously reviewed P3412R1 during the 2025-02-26 SG16 meeting. 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.