On Wed, Dec 1, 2021 at 8:07 PM Tom Honermann via SG16 <sg16_at_[hidden]>
wrote:

> On 12/1/21 12:46 PM, Victor Zverovich wrote:
>
> Some details about the escaping mechanism that has been implemented
> for P2286R3: Formatting Ranges in the fmt library. It basically follows the
> Rust's Unicode escaping (
> https://doc.rust-lang.org/src/core/char/methods.rs.html#399-420) with the
> following differences:
>
> * Grapheme extended code points are not escaped although I don't see any
> problems with implementing this as well.
> * The escape format uses C++ Unicode escape sequences rather than Rust's.
> * Invalid code unit sequences are escaped for round trip (Rust doesn't
> need to do this because it has validation).
>
> So the escaping logic for code points that need escaping is as follows:
>
> \t, \r, \n, \, ' and " are escaped using their usual escape sequences such
> as literal text \t (not tab)
> Code points in the range [0, 0x100) are escaped as \xhh, e.g. \x7f
> Code points in the range [0x100, 0x10000] are escaped as \uhhhh,
> e.g. \u0378
> Code points in the range [0x10000, 0x110000] are escaped as \Uhhhhhhhh,
> e.g. \U0002a6de
> For invalid code unit sequences each individual code unit is escaped as
> \xhh (this doesn't happen in Rust or Python because those have validation
> but using hex escapes is a pretty natural extension)
>
> What is the motivation for using hex escapes for code points 0 through
> 0x100 instead of UCN notation? UCN notation would retain the semantic
> intent through transcoding. I like the use of hex escapes for preserving
> the code units in invalid code unit sequences.
>
Also, to clarify... rust doesn't escape printable ascii, this is the intent
here too, right?


> Tom.
>
>
> This is obviously for the Unicode case. The non-Unicode case should be
> specified separately using our usual implementation-defined wording.
>
> Cheers,
> Victor
>
>
> On Wed, Dec 1, 2021 at 7:26 AM Victor Zverovich <
> victor.zverovich_at_[hidden]> wrote:
>
>> > Is there value in specifying it?
>>
>> Yes, I think there is value in handling this case consistently across
>> implementations. Option 1 is problematic for width = 2 and not just with
>> alignment to the end so it looks like 3 is the most sensible one (option 2
>> is clearly wrong and just there for completeness).
>>
>> Cheers,
>> Victor
>>
>>
>>
>> On Tue, Nov 30, 2021 at 10:13 AM Tom Honermann via SG16 <
>> sg16_at_[hidden]> wrote:
>>
>>> 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.
>>>
>>>
>>> --
>>> SG16 mailing list
>>> SG16_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>>
>>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>