Date: Sun, 23 Jan 2022 06:58:14 -0500
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
>
>
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
>
>
Received on 2022-01-23 11:58:29