Ah, you are right, thanks, Victor. I forgot that quotes are inserted as
part of the field formatting. I corrected the comment in
https://github.com/cplusplus/nbballot/issues/515 to remove that example.

Tom.

On 11/25/22 11:23 AM, Victor Zverovich wrote:
> This example is equivalent to one of the examples in the paper (s6).
>
> - Victor
>
> On Fri, Nov 25, 2022 at 8:03 AM Corentin <corentin.jabot_at_[hidden]> wrote:
>
> I think the example, properly quoted, would be useful - if only
> for non implementers reading the standard.
>
> Thanks,
> Corentin
>
> On Fri, Nov 25, 2022 at 4:57 PM Victor Zverovich
> <victor.zverovich_at_[hidden]> wrote:
>
> Intentional or not but it is completely wrong because the
> output is e"\u{301}" not e\u{301} (outer quotes omitted for
> clarity). Implementations don't need to do anything special
> here. Same with the new example you provided.
>
> - Victor
>
> On Fri, Nov 25, 2022 at 6:59 AM Tom Honermann
> <tom_at_[hidden]> wrote:
>
> On 11/24/22 12:16 PM, Victor Zverovich wrote:
>> As promised here's a paper with the wording for the
>> approved escaping changes:
>> https://isocpp.org/files/papers/P2713R0.html.
>>
>> Note that one example in
>> https://github.com/cplusplus/nbballot/issues/515 (the one
>> that uses s8) is incorrect so I didn't include it.
>
> That example was intentional. The example is:
>
> string s8 = format("e{:?}", "\u0301"); // s8 has
> value "e\u{301}"
> // (the
> combining character is escaped since it does
> // not
> follow a non-escaped non-combining character
> //
> produced from the same field)
>
> The formatted field argument begins with a combining
> character. I wrote this example with the assumption that
> we don't want to require implementations to have to be
> aware of characters from outside of the field content to
> be formatted as that seems like it would introduce
> additional complexity that is not required today; please
> correct me if I'm mistaken.
>
> A similar example follows. We certainly wouldn't want the
> combining character from the field to combine with the
> escaped tab character sequence in this case.
>
> string s9 = format("\t{:?}", "\u0301"); // s9 has
> value "\t\u{301}"
> // (the
> combining character is escaped since it does
> // not
> follow a non-escaped non-combining character
> //
> produced from the same field)
>
> Tom.
>
>>
>> Cheers,
>> Victor
>>
>> On Fri, Nov 11, 2022 at 6:20 PM Bryce Adelstein Lelbach
>> aka wash <brycelelbach_at_[hidden]> wrote:
>>
>> Please email me when you have it.
>>
>> On Fri, Nov 11, 2022 at 1:58 PM Victor Zverovich
>> <victor.zverovich_at_[hidden]> wrote:
>>
>> > Can you have it available for our November 30th
>> meeting (that I still need to create a calendar
>> entry for)?
>>
>> Sure.
>>
>> - Victor
>>
>> On Fri, Nov 11, 2022 at 1:56 PM Tom Honermann
>> <tom_at_[hidden]> wrote:
>>
>> Can you have it available for our November
>> 30th meeting (that I still need to create a
>> calendar entry for)?
>>
>> Tom.
>>
>> On 11/11/22 6:54 PM, Victor Zverovich via
>> Lib-Ext wrote:
>>> I am putting together a paper but it won't
>>> be ready today and probably needs to be
>>> looked at by SG16 to check the wording.
>>>
>>> - Victor
>>>
>>> On Fri, Nov 11, 2022 at 1:48 PM Corentin
>>> <corentin.jabot_at_[hidden]> wrote:
>>>
>>> I think Victor is working on it, I'm
>>> happy to co author.
>>>
>>> On Fri, Nov 11, 2022, 13:44 Bryce
>>> Adelstein Lelbach aka wash
>>> <brycelelbach_at_[hidden]> wrote:
>>>
>>> We voted to resolve format escaping
>>> NB comments US-38-098 and FR-005-134
>>> at the 2022-11 Kona meeting in both
>>> SG16 and Library Evolution.
>>>
>>> However, the resolution we voted on
>>> is not as simple as "adopt the
>>> proposed resolution in the
>>> comments". It took me 10 minutes of
>>> reading minutes and poll results to
>>> determine what exactly we had approved.
>>>
>>> Therefore, I'm going to need a short
>>> paper that resolves these NB
>>> comments for the Library Evolution
>>> electronic poll. It should have a
>>> brief overview and motivation (I'm
>>> not looking for much there) and the
>>> specific wording that resolves these
>>> NB comments.
>>>
>>> Ideally, I'd get the paper today, or
>>> at least by 2022-11-14 so that it
>>> can be included in the post meeting
>>> Library Evolution polls. At the
>>> latest, I'd need it by 2023-01-01.
>>>
>>> --
>>> Bryce Adelstein Lelbach aka wash
>>> (he/him/his)
>>> US Programming Language Standards Chair
>>> ISO C++ Library Evolution Chair
>>> Principal Architect @ NVIDIA
>>> --
>>>
>>>
>>> _______________________________________________
>>> Lib-Ext mailing list
>>> Lib-Ext_at_[hidden]
>>> Subscription:https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
>>> Link to this post:http://lists.isocpp.org/lib-ext/2022/11/24215.php
>>
>>
>>
>> --
>> Bryce Adelstein Lelbach aka wash (he/him/his)
>> US Programming Language Standards Chair
>> ISO C++ Library Evolution Chair
>> Principal Architect @ NVIDIA
>> --
>>