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.

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