LWG3576: Clarifying fill character in std::format

[jwakely]

SG16 needs to clarify the intended design for https://cplusplus.github.io/LWG/issue3576

"The fill character should at least be a codepoint, definitively - Whether we allow it to be a grapheme cluster is an interesting question and probably requires some discussion.
We definitely do not want to use the term character in such an ambiguous context!"

"The wording is definitely wrong anyway, considering that it only changes a non-normative note."

[tahonermann]

SG16 discussed this issue at our August 25th, 2021 telecon.

The following polls were conducted:

Poll: Recommend that the proposed resolution for LWG3576 should be adopted, with the modification that the fill character must not contain '{' or '}' as part of the extended grapheme cluster.

SF	F	N	A	SA
0	1	1	3	2

• Attendance: 7
• Consensus against

Poll: The format fill character should be defined as "any codepoint of the literal encoding other than '{' or '}'".

SF	F	N	A	SA
3	3	1	0	0

• Attendance: 7
• Strong consensus in favor

My interpretation of the polls is that SG16 recommends that the code unit sequence in the format string that designates the fill character consist of a single code unit sequence (potentially containing multiple code units) that designates a single code point to be used as the fill character. The code unit sequence must not correspond to the encoding of the { or } characters in the encoding of the format string. The designated code point must correspond to a character that is representable in the encoding of the format string. The designated code point may correspond to a character with an estimated width other than 1.

@peter-b acted as chair at this meeting; I was not present. I'm left with the following questions that may warrant further follow up in SG16.

1. Can the format string designate the { or } characters through use of an escape sequence?
2. Are implementations required to consider the estimated width of the fill character when substituting it into the formatted results? If not, should normative encouragement to do so be added?

[tab:format.align] suggests that width estimation must not be considered when inserting fill characters. This table appears to be missing wording to insert fill characters for the < and > options.

I'll retain the SG16 label for the moment while following up on these last two questions with SG16.

[tahonermann]

My last comment noted two issues for SG16 to follow up on. The first is a non-issue that does not require follow up; escape sequences cannot be used to evade unintended delimiter matching since the format string is a cooked string (escape sequences are already processed). The second issue is now tracked by #1150.

I'm still retaining the SG16 label for now as the proposed resolution for this issue needs some tweaking; recent discussion indicates that we may have to specify "multibyte character" rather than "code point" in the wording in order to accommodate shift-state encodings that don't have a clear concept of "code point".

[tahonermann]

SG16 discussed (a draft of) P2572R0 at its 2022-06-08 telecon. The following poll was taken:

• Poll 1: Revise D2572R0 "std::format() fill character allowances" as discussed,
  and forward the paper so revised to LEWG as the recommended resolution of LWG3576
  and LWG3639.

  • Attendance: 8 (2 abstention)

    SF	F	N	A	SA
    3	3	0	0	0

  • Consensus in favor.

The changes in the published P2572R0 revision reflect the SG16 requested changes.

Removing the SG16 label; this is ready for LWG pending approval of issue #1260 and (a revision of) P2572 by LEWG.