Date: Sat, 27 Nov 2021 19:30:56 -0500
SG16 will hold a telecon on Wednesday, December 1st at 19:30 UTC
(timezone conversion
<https://www.timeanddate.com/worldclock/converter.html?iso=20211201T193000&p1=1440&p2=tz_pst&p3=tz_mst&p4=tz_cst&p5=tz_est&p6=tz_cet>).
The agenda is:
* LWG3639: Handling of fill character width is underspecified in
std::format <https://wg21.link/lwg3639>
* P2286R3: Formatting Ranges <https://wg21.link/p2286r3>
For LWG3639 <https://wg21.link/lwg3639>, the issue discussion enumerates
three possible solutions, though others are possible. There is also a
related wording omission; table [tab.format.align]
<http://eel.is/c++draft/tab:format.align> doesn't actually specify how
alignment is achieved for the '<' and '>' options (the wording doesn't
state to insert fill characters as it does for the '^' option).
Additionally, further tweaking (and possibly new LWG issues) may be
needed to address these concerns:
1. If the width of the value exceeds the field width, then alignment to
the end of the available space is not possible.
[format.string.std]p8 <http://eel.is/c++draft/format.string.std#8>
should be updated to address this possibility, presumably by noting
that the content may overflow the available space resulting in
misalignment.
std::format("{:X>1}}, 9999);
2. If the estimated width of the fill character is greater than 1, then
alignment to the end of the available space might not be possible.
The choice here is whether to under-fill or over-fill the available
space. This possibility is avoided if fill characters are restricted
to characters with an estimated width of exactly 1.
std::format("{:🤡>4}", 123);
For P2286R3 <https://wg21.link/p2286r3>, LEWG requested
<https://lists.isocpp.org/sg16/2021/11/2845.php> that SG16 consider the
ramifications for support of user defined delimiters. We should also
discuss the "?" specifier proposed to explicitly opt in to quoted and
escaped formats for std::string, std::string_view, and arrays of
char/wchar_t.
Tom.
(timezone conversion
<https://www.timeanddate.com/worldclock/converter.html?iso=20211201T193000&p1=1440&p2=tz_pst&p3=tz_mst&p4=tz_cst&p5=tz_est&p6=tz_cet>).
The agenda is:
* LWG3639: Handling of fill character width is underspecified in
std::format <https://wg21.link/lwg3639>
* P2286R3: Formatting Ranges <https://wg21.link/p2286r3>
For LWG3639 <https://wg21.link/lwg3639>, the issue discussion enumerates
three possible solutions, though others are possible. There is also a
related wording omission; table [tab.format.align]
<http://eel.is/c++draft/tab:format.align> doesn't actually specify how
alignment is achieved for the '<' and '>' options (the wording doesn't
state to insert fill characters as it does for the '^' option).
Additionally, further tweaking (and possibly new LWG issues) may be
needed to address these concerns:
1. If the width of the value exceeds the field width, then alignment to
the end of the available space is not possible.
[format.string.std]p8 <http://eel.is/c++draft/format.string.std#8>
should be updated to address this possibility, presumably by noting
that the content may overflow the available space resulting in
misalignment.
std::format("{:X>1}}, 9999);
2. If the estimated width of the fill character is greater than 1, then
alignment to the end of the available space might not be possible.
The choice here is whether to under-fill or over-fill the available
space. This possibility is avoided if fill characters are restricted
to characters with an estimated width of exactly 1.
std::format("{:🤡>4}", 123);
For P2286R3 <https://wg21.link/p2286r3>, LEWG requested
<https://lists.isocpp.org/sg16/2021/11/2845.php> that SG16 consider the
ramifications for support of user defined delimiters. We should also
discuss the "?" specifier proposed to explicitly opt in to quoted and
escaped formats for std::string, std::string_view, and arrays of
char/wchar_t.
Tom.
Received on 2021-11-27 18:30:59