This is your friendly reminder that this telecon will take place tomorrow.

If we manage to get through both LWG3639 and P2286R3, we'll resume
discussion of P2361R4 (Unevaluated strings) and potentially poll
forwarding it.

Tom.

On 11/27/21 7:30 PM, Tom Honermann via SG16 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.
> 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.
>
>