Sounds good to me, but SG16 should review first. I anticipate such review occurring during one of our two February telecons.

Tom.

On 1/23/22 7:30 PM, JeanHeyd Meneide via SG16 wrote:
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@jfbastien.com> 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@lists.isocpp.org> 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@gmx.net> 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@lists.isocpp.org <mailto:sg16@lists.isocpp.org>> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16