On 10/6/21 6:02 PM, Victor Zverovich wrote:
> I'm a bit skeptical about the "briefly" part considering that past
> performance but I'll open an LWG issue.

I hear that time is relative and I suspect that, relative to our prior
discussion of concerns around std::format(), discussion of this aspect
will be objectively brief! (please don't let me be wrong!) :)

Thanks for filing the issue. Please let me know once there is an LWG
issue number for it.

Tom.

>
> - Victor
>
> On Wed, Oct 6, 2021 at 11:09 AM Jens Maurer via SG16
> <sg16_at_[hidden] <mailto:sg16_at_[hidden]>> wrote:
>
> On 22/09/2021 20.14, Tom Honermann via SG16 wrote:
> > SG16 discussed LWG3576: Clarifying fill character in std::format
> <https://github.com/cplusplus/papers/issues/1090
> <https://github.com/cplusplus/papers/issues/1090>> during its
> August 25th telecon
> <https://github.com/sg16-unicode/sg16-meetings#august-25th-2021
> <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?
>
> Given the mechanics of the core language, I believe there is no open
> question that can be resolved at the level of a library function.
>
> > 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 second item, [tab:format.align]
> <http://eel.is/c++draft/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.
>
> We already have wording that tries to approximate the width of
> characters.
> It seems plausible to apply that to fill characters as well.
>
> > I think it would be useful to briefly discuss and poll these
> questions in an SG16 telecon, but I'm open to suggestions.
>
> I'd suggest that Victor creates an LWG issue for that question (if
> it doesn't exist
> already), together with proposed wording, and have that briefly
> acked by SG16 (not
> today).
>
> Jens
> --
> 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>
>