On 6/8/22 12:48 PM, Victor Zverovich wrote:
> I think the term "specifier" is better suited for fill while "option"
> is better suited for enumerable / flag specifiers.

I don't have a preference here. Would you be ok leaving the proposed
wording as is for SG16 and then addressing it in LWG review later? The
current changes replace "specifier" with "option" for the align, um,
thing, so we'll be sure to have an opportunity for LWG to consider what
they prefer.

I did a quick review of [format.string.std]
<http://eel.is/c++draft/format.string.std> (without the proposed
changes). The terminology used for each of the grammar productions is
listed below./
/

  * /fill-and-align/: none (neither specifier nor option)
  * /fill/: none (neither specifier nor option)
  * /align/: specifier
  * /sign/: option
  * /#/: option
  * /0/: none (neither specifier nor option).
  * /width/: none (neither specifier nor option)
  * /precision/: none (neither specifier nor option)
  * /L/: option
  * /type/: option

Tom.

>
> - Victor
>
> On Tue, Jun 7, 2022 at 11:45 AM Mark de Wever via SG16
> <sg16_at_[hidden]> wrote:
>
> 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
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>