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