On 11/12/2021 23.00, Victor Zverovich via SG16 wrote:
> Hi Tom and other Unicoders,
>
> Can we review an updated revision of P2286 (https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html <https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html>) during the upcoming meeting since there is still chance that it can target C++23? This revision addresses the SG16 feedback, particularly around escaping (https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html#escaping-behavior <https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html#escaping-behavior>). I think it's way more important and time sensitive than LWG issues related to fill.

3.2.7 escaping behavior

I think this needs to be rephrased using "UCS scalar values".
The term "code point" includes surrogate code points, which
should not be copied as-is, I think. (They might be lone
surrogates, which are better represented using hex escapes.)

In the first bullet, when talking about "code points", I'd
prefer to see a list using Unicode character names
(e.g. "U+0009 CHARACTER TABULATION") rather than character
literals (that need escaping interpretation).

In the last bullet, the "Otherwise" does not refer to a
preceding "if", it seems, so "otherwise" should not be there.
Also, "which" -> "that" (restrictive).

It seems that the strings shown here are intended to be
lexed as string literals, with interpretation of escapes.
That is surprising to me.
Maybe it would help to refer to [lex] grammar non-terminals,
e.g. "hexadecimal-escape-sequence" (italics).

Do we use uppercase or lowercase hex?

Jens