Dear JF,

     If you and everyone else approve, I'm more than happy to make that
happen.

Sincerely,
JeanHeyd

On Sun, Jan 23, 2022 at 7:13 PM JF Bastien <cxx_at_[hidden]> wrote:

> Since it's not a new feature, but rather a bugfix, then we still have time
> to make it to 23. Would you want me to do so? I haven't scheduled EWG
> meetings fro 2022 yet, giving everyone a break.
>
> On Sun, Jan 23, 2022 at 8:58 PM JeanHeyd Meneide via SG16 <
> sg16_at_[hidden]> wrote:
>
>> Dear Jens,
>>
>> I had no intention of filing (or asking someone to file) an NB
>> comment, albeit now that the paper is released I don't think I could stop
>> someone from doing it. I don't mind if it's C++26 material because it's a
>> DR, so it would always apply to C++20. (Albeit, it's probably better if
>> it's fixed sooner rather than later.)
>>
>> If EWG can squeeze it in and everyone's fine with it, I'll try to
>> attend an EWG meeting and answer questions and get it forwarded so I can do
>> CWG -> plenary for C++23!
>>
>> Sincerely,
>> JeanHeyd
>>
>> On Sun, Jan 23, 2022 at 4:12 AM Jens Maurer <Jens.Maurer_at_[hidden]> wrote:
>>
>>> On 23/01/2022 05.41, JeanHeyd Meneide wrote:
>>> > Thank you for the feedback! Most of it has been applied. The
>>> paper title does say "Fixes" but this probably does just classify as a
>>> single fix, so I'll change the title. Originally, I was dabbling with the
>>> idea of adding pointer conversions from UTF-8 string literals (and only
>>> UTF-8 string literals) to (in order of preference for overloading and
>>> conversion ranking) const char8_t* -> const unsigned char* -> const char*,
>>> but that paper would be COLOSSAL. I'd likely require an implementation to
>>> prove it works in practice, too, since it would touch conversion rules,
>>> ranking, and overload resolution.
>>>
>>> > This single fix is more than enough to get us by for now, and
>>> already has ample existing practice (it was the way it was before!).
>>>
>>> The "target" of the paper says C++26.
>>>
>>> I thought you wanted it considered as a C++20 bug fix,
>>> which should go into C++23 ?
>>>
>>> It's certainly short enough and bug-fixy enough to go through
>>> EWG and CWG in the coming months, and I'd rather have it
>>> discussed now as opposed to dealing with an NB comment later.
>>>
>>> Jens
>>>
>>>
>>>
>>> > On Sat, Jan 22, 2022 at 4:31 PM Jens Maurer via SG16 <
>>> sg16_at_[hidden] <mailto:sg16_at_[hidden]>> wrote:
>>> >
>>> > ...
>>> >
>>> > - Wording:
>>> >
>>> > …
>>> >
>>> > However, we discuss here "UTF-8 string literal", and a few words
>>> later we talk
>>> > about a "char8_t-typed string-literal". Is there any intended
>>> difference between
>>> > these? If so, I need help in seeing the difference. If not,
>>> just say
>>> > ", or by such a string literal enclosed in braces."
>>> >
>>> >
>>> > This was actually just due to copying the previous sentence and
>>> trying to have an almost carbon-copy word-for-word here. Your formulation
>>> is much better, so I'm just going to go with that! I also changed "can" in
>>> the previous sentence to "may" as well, so we don't have a weird can/may or
>>> may/can split. Updated paper here:
>>> https://thephd.dev/_vendor/future_cxx/papers/d2513.html <
>>> https://thephd.dev/_vendor/future_cxx/papers/d2513.html>
>>> >
>>> > Sincerely,
>>> > JeanHeyd Meneide
>>>
>>> --
>> SG16 mailing list
>> SG16_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>
>