On 6/8/22 1:17 PM, Victor Zverovich wrote:
> > 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.

I'm inclined to leave it as is for now; just to ensure we don't forget
to discuss it in LWG later. The paper also has a couple of other
drive-by fixes already.

Tom.

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