On Sun, Nov 28, 2021, 01:31 Tom Honermann via SG16 <sg16_at_[hidden]>
wrote:

> 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.
>
> That seems like a purely lwg concern


> 1. 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);
>
>
Is there value in specifying it? Neither solutions are great nor terrible,
i think saying unspecified would be fine, so would underfilling i guess.

Hopefully, we are consistent and choose option 1 among those specified in
the lwg issue


>
> 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.
>
Not sure the quoted thing is in our purview.

For the delimiter, we should support codepoints, to be consistent with
everything else. The issue is the we don't have experience with that afaik.
If we agree on codepoints, we are very close to arbitrary strings, which is
also an option. The issue there is finding where the delimiter ends in the
format string.
Whatever we pick is likely to get backed in ABI.


Tom.
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>