Date: Wed, 6 Oct 2021 20:09:12 +0200
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 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
Received on 2021-10-06 13:09:20