Date: Wed, 6 Oct 2021 15:02:12 -0700
I'm a bit skeptical about the "briefly" part considering that past
performance but I'll open an LWG issue.
- Victor
On Wed, Oct 6, 2021 at 11:09 AM Jens Maurer via SG16 <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> 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?
>
> 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> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
performance but I'll open an LWG issue.
- Victor
On Wed, Oct 6, 2021 at 11:09 AM Jens Maurer via SG16 <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> 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?
>
> 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> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
Received on 2021-10-06 17:02:25