SG16 discussed LWG3576: Clarifying fill character in std::format
<https://github.com/cplusplus/papers/issues/1090> during its August 25th
telecon
<https://github.com/sg16-unicode/sg16-meetings#august-25th-2021>. I was
absent for that telecon (thank you, Peter, for running the show!), but
have reviewed the minutes. I updated the linked github issue with the
polls taken today. Please review my interpretation of the polls and
offer any corrections via this email thread.

There are two outstanding questions that were not polled and where I'm
uncertain if we have consensus.

 1. Can the format string designate the '{' or '}' characters (or any
    other character) 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?

For the first item, I expect consensus to be no for implementation
reasons. std::format() observes a cooked string and therefore cannot
differentiate "{" and "\u007b". This presumably excludes use of octal or
hex escapes as well if they happen to designate the ordinal value of '{'
or '}' in the literal encoding.

For the second item, [tab:format.align]
<http://eel.is/c++draft/tab:format.align> is clear that, at least for
the ^ option (fill character wording appears to be missing for the < and
> options), that the fill character is inserted /n/ times. It is not
specified how a value for /n/ is derived. If /n/ is determined based on
"columns" to fill, then if the fill character has a estimated width
other than 1, then the field will be misaligned. However, if n is
determined based on both "columns" to fill and the estimated width of
the fill character, then the field will be properly aligned assuming
that the number of columns to fill is a multiple of the estimated width
of the fill character.

I think it would be useful to briefly discuss and poll these questions
in an SG16 telecon, but I'm open to suggestions.

Tom.