Date: Fri, 25 Nov 2022 08:23:48 -0800
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 listLib-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
>>>> --
>>>>
>>>
- 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 listLib-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
>>>> --
>>>>
>>>
Received on 2022-11-25 16:23:59