On 28/11/2021 10.42, Corentin Jabot via SG16 wrote:
>
> On Sun, Nov 28, 2021, 01:31 Tom Honermann via SG16 <sg16_at_[hidden] <mailto:sg16_at_[hidden]>> wrote:

> 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

How so? There is at least the possibility to truncate the field
contents instead, and there ought to be a design-level decision what
should be done.

> 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.

But the compile-time format string parser might not necessarily understand
the details of the literal encoding, so it's unclear how codepoints map to
code units. Or are you saying that the rest of std::format already requires
detailed understanding, anyway?

Jens