On 2/25/26 3:10 PM, Corentin Jabot via SG16 wrote:
>
>
> 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.
>
Ignore the examples above. They are nonsense that I put together too
quickly without thinking things through. I was trying to find counter
examples to the following claim from section 7.1 of P3412R3
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3412r3.pdf>.
I failed. Thanks to Barry for correcting me offline.

    Note that lambdas, which may contain any type of code including for
    instance goto labels, always contain this code inside matched
    braces, so any colons will be ignored when detecting the
    expression-field end. The same goes for /statement-expressions/ of
    gcc and /blocks/ of Clang.

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

That matches what I was thinking and what lead me to ask the question.

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

Yes, that is a LEWG question. But it is relevant to SG16 with regard to
the ability to specify the '[', ']', '{', '}', '#', and '##' tokens in
extraction fields in source files that have an encoding that doesn't
support them. If macro expansion doesn't occur, then we presumably need
to support use of digraphs or UCNs in some way.

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