Hello,

A couple of comments on P2572R0

> Change in 22.14.2.2 [format.string.std] paragraph 11:

The intent is not clear to me here.

I don't think there are a precondition that unicode encoded strings are well-formed in format (and if there was that change is not necessary as there can be no codepoints that are not scalar value in a well-formed sequence), and if we want to enforce well-formedness i'd rather that it be stated that way. 

On the other hand, if we do not intend to ensure well-formedness, we should be mindful that

if we allow ill-formed sequences, then the standard practice is to replace isolate surrogate by

� whose width is definitively 1 [1], and so the changes in 22.14.2.2 requires, in my mind further discussion and a broader solution. I would keep that a separate issue.

Unless you want to clearly state "the width of surrogates is undefined" or something like that.

Beside, I also don't think it would be useful to replace code point by scalar values in places where there is already a precondition or no possibility to have isolated surrogates, as scalar value, beside being a mouthful, is only applicable to unicode (unlike codepoint), and in places where well-formedness is desirable, "Precondition foo is a well-formed sequence in the bar encoding" would take care of scalar values.

This sounds like something that would be appropriate to discuss in LWG. This change is intended to be a drive-by correction and specifically not a design change. If LWG wishes to reject that change, that won't affect the rest of the paper.

I'm not aware of any wording that describes what happens if an ill-formed Unicode string is provided as the format string; that seems like UB by omission and implementations appear to agree. I agree that any change to perform character substitution should be addressed in a separate paper.

The wording in this context is Unicode specific; I agree we should not use UCS scalar value in a general sense.

Change in 22.14.2.2 [format.string.std] paragraph 3:

A couple of comments on P2572R0

The 🤡 (U+1F921 CLOWN FACE) emoji has an estimated width of 2. The examples above that include that character illustrate the effect of the estimated width when that character is used as a fill character as opposed to when it is used as a formatting argument.

I had trouble understanding that, I would suggest including the information that 🤡 is of width 2 directly within the example or in a separate note directly below the example.

I'm not sure I'm following; why would relocating the note improve comprehension? Perhaps the note would read better as two paragraphs as below?

[ Note 3: If the width option is absent, then the field width is the estimated width of the formatted argument and the alignment option has no effect. If the estimated width of the formatted argument matches or exceeds the field width, then both the alignment and width options have no effect.

The width of any fill character is assumed to be 1. The 🤡 (U+1F921 CLOWN FACE) emoji has an estimated width of 2. The examples above that include that character illustrate the effect of the estimated width when that character is used as a fill character as opposed to when it is used as a formatting argument. — end note ]

" The examples above that include that character illustrate the effect of the estimated width when that character is used as a fill character as opposed to when it is used as a formatting argument." is probably superfluous and could be omitted.

Do we need examples with extended grapheme clusters?

ie 🐻‍❄️ has 3 codepoints, width 1, but its use as fill-option is invalid

🐻‍❄️ is actually 4 code points (U+1F43B, U+200D, U+2744, U+FE0F) and has a width of 2 since its first code point is U+1F43B per [format.string.std]p11.

There are such examples in the prose. I'm ambivalent with regard to whether we add such an example in the wording. If we do, I'm assuming something like the following would be what you want? (I substituted an EGC consisting of 2 code points with an estimated width of 1).

string s9 = format("{:é^6}", "x");       // ill-formed; é is U+0065, U+0301.
string s10 = format("{:*^6}", "ééé");    // value of s10 is "*ééé**"

The rest looks great to me

Thank you.

Tom.

Thanks,

Corentin

[1] Unicode Standard 14.0 - 2.7 Unicode Strings

Whenever such strings are specified to be in a particular Unicode encoding form—even
one with the same code unit size—the string must not violate the requirements of that
encoding form. For example, isolated surrogates in a Unicode 16-bit string are not allowed
when that string is specified to be well-formed UTF-16. A number of techniques are available for dealing with an isolated surrogate, such as omitting it, converting it into U+FFFD
replacement character to produce well-formed UTF-16, or simply halting the processing of the string with an error. (See Section 3.9, Unicode Encoding Forms.)