Date: Tue, 7 Jun 2022 23:59:40 -0400
On 6/7/22 2:45 PM, Mark de Wever 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.
Thank you, Mark!
> https://raw.githack.com/tahonermann/std-proposals/master/d2572r0.htmlI 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.
I had noticed the inconsistency, but wasn't sure if there was some
intention behind it. Thank you; I applied your suggested change.
> 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
Done.
>
> 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
I made an update to [format.string.std]p2 to clarify that the fill
character is restricted to a single UCS scalar value for Unicode
encodings. Given the prior discussions, your raising this again, and
Corentin's response, I think this is worth clarifying in the (normative)
wording. Please take a look.
>
> 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.
Excellent idea! Done!
Please reload the draft from
https://raw.githack.com/tahonermann/std-proposals/master/d2572r0.html.
It should now have a date of 2022-06-08.
Tom.
>
>
> Mark
> 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.
Thank you, Mark!
> https://raw.githack.com/tahonermann/std-proposals/master/d2572r0.htmlI 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.
I had noticed the inconsistency, but wasn't sure if there was some
intention behind it. Thank you; I applied your suggested change.
> 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
Done.
>
> 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
I made an update to [format.string.std]p2 to clarify that the fill
character is restricted to a single UCS scalar value for Unicode
encodings. Given the prior discussions, your raising this again, and
Corentin's response, I think this is worth clarifying in the (normative)
wording. Please take a look.
>
> 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.
Excellent idea! Done!
Please reload the draft from
https://raw.githack.com/tahonermann/std-proposals/master/d2572r0.html.
It should now have a date of 2022-06-08.
Tom.
>
>
> Mark
Received on 2022-06-08 03:59:41