Hi Tom,

> The link to D2572R0 above is a live link. The revision currently there is
> unchanged from our prior review. I expect to complete updates in the next
> day or so and will send an update and change log when done. Please try to
> supply any wording feedback on the mailing list before the meeting; I hope
> we won't need to spend much more time on this paper.

Some feedback based on the latest changes.

I noticed you use the word specifier, for example in "fill specifier".
In the current wording most places use option instead of specifier.

The notable exception is http://eel.is/c++draft/format.string.std#3
which uses "align specifier". I would suggest to change "specifier"
to "option" in the new wording and fix "align specifier" as drive-by
fix. The generic term "format specifiers" is used in more places.

A small suggestion for Note 3
  If the estimated width of the formatted argument <ins>matches or
  </ins>exceeds the field width, then both the alignment and width
  options have no effect

I'm still a bit concerned that we don't really specify what we mean with
a character for the fill character. Looking at the number of options
that have been discussed in the past, and the fact we want to move this
paper forward, I would suggest not to change the wording but instead
modify Example 2

  string s5 = format("{:6d}", c); // value of s5 is " 120"
  string s6 = format("{:6}", true); // value of s6 is "true "
  string s7 = format("{:*>6}", "12345678"); // value of s7 is "12345678"
  <ins>string s8 = format("{:🤡^6}", 'x'); // value of s8 is "🤡🤡x🤡🤡🤡"</ins>

This also demonstrates the expected width of the fill character is
assumed to be 1.


Mark