> Would you be ok leaving the proposed wording as is for SG16 and then
addressing it in LWG review later?

Sure. It is very minor and definitely in the scope of LWG, not SG16. I
would only recommend reverting the change in

The *align* specifieroption applies to all argument types.

since it has nothing to do with the paper.

- Victor

On Wed, Jun 8, 2022 at 10:08 AM Tom Honermann <tom_at_[hidden]> wrote:

> 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
>>
>