Dear Unicoders,

1. The answer is clearly yes because as Tom correctly points out the
difference between escaped and unescaped characters is unobservable in
std::format.
2. I don't think we have such a requirement in the wording right now but we
should probably do something about it. Let's open another LWG issue?

Cheers,
Victor

On Wed, Sep 22, 2021 at 11:15 AM Tom Honermann via SG16 <
sg16_at_[hidden]> wrote:

> 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.
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>