> On Jan 27, 2025, at 3:22 PM, Corentin Jabot via SG16 <sg16_at_[hidden]> wrote:
>
> On Mon, Jan 27, 2025 at 7:00 PM Tom Honermann via SG16 <sg16_at_[hidden] <mailto:sg16_at_[hidden]>> wrote:
>> Handling of escape sequences needs more specification. This does not appear to have been addressed.
> Meh. Should we want restrictions, they would be the same for static_assert, and I tend to see it's purely QOI
> https://compiler-explorer.com/z/nresK1qrd <https://compiler-explorer.com/z/nresK1qrd>
My thoughts are that we treat the supplied message like an unevaluated string.

Quoting [lex.string.uneval]:

> Each universal-character-name and each simple-escape-sequence in an unevaluated-string is replaced by the
> member of the translation character set it denotes. An unevaluated-string that contains a numeric-escape-
> sequence or a conditional-escape-sequence is ill-formed.

My suggestion would be to add “and is processed as an unevaluated-string.” To the end of p2 of the library wording.

That should handle making numeric and conditional escape sequences ill-formed, and map the universal names and simple escape sequences to their corresponding sequence of UTF-8 encoded code points.

AlisdairM