C++ Logo

sg16

Advanced search

Re: Comments on P2513R0 char8_t Compatibility and Portability Fixes

From: JF Bastien <cxx_at_[hidden]>
Date: Mon, 24 Jan 2022 09:13:18 +0900
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
>

Received on 2022-01-24 00:13:31