Date: Sat, 22 Jan 2022 23:41:21 -0500
Dear Jens,
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!).
On Sat, Jan 22, 2022 at 4:31 PM Jens Maurer via SG16 <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
Sincerely,
JeanHeyd Meneide
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!).
On Sat, Jan 22, 2022 at 4:31 PM Jens Maurer via SG16 <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
Sincerely,
JeanHeyd Meneide
Received on 2022-01-23 04:41:34