On 10/6/21 1:06 PM, Victor Zverovich wrote:
> 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?

Opening an LWG issue seems reasonable to me. You'll do so?

Tom.

>
> Cheers,
> Victor
>
> On Wed, Sep 22, 2021 at 11:15 AM Tom Honermann via SG16
> <sg16_at_[hidden] <mailto: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] <mailto:SG16_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
> <https://lists.isocpp.org/mailman/listinfo.cgi/sg16>
>