Date: Sun, 6 Dec 2020 17:41:00 -0500
On 12/4/20 10:48 AM, JeanHeyd Meneide via SG16 wrote:
> Dear SG16 and C/C++ Liaison Group,
>
> N2594 - https://thephd.github.io/_vendor/future_cxx/papers/C%20-%20Mixed%20Wide%20String%20Literal%20Concatenation.html
> - was accepted by WG14 this meeting and we just adjourned. This means
> both languages have feature parity in this regards! 🎉
Excellent! Nice work!
>
> BUT!
>
> WG14 also wants to look into -- after removing it -- spending
> some time coming up with well-defined combination mechanism. We would
> like to have ill-formedness (C++) / constraint violations (C) if the
> conversion to the final chosen encoding do not work, to give people
> good guarantees above e.g. synthesizing Unicode into an wide string
> literal or synthesizing wide string data into Unicode literals.
Was any particular use case discussed? Or just a general preference to,
given something like this:
#define NAME u8"foo"
#define VERSION "5"
void emit(const char16_t*);
to be able to do something like this:
emit(u"" NAME "-" VERSION);
as opposed to having to do conversions and concatenations at run-time?
>
> (Also, I forgot to ask if they wanted to do something similar to
> P1041 - https://wg21.link/p1041 - yet...)
That would be good to get on the agenda for the next WG14 meeting. It
would be great if we can start making progress on all of the following
issues! My understanding is that any proposals targeting C2X must be
proposed by August 27th, 2021.
* WG14: Make char16_t/char32_t string literals be UTF-16/32
<https://github.com/sg16-unicode/sg16/issues/54>
* WG14 N2231: char8_t: A type for UTF-8 characters and strings
<https://github.com/sg16-unicode/sg16/issues/5>
* WG14: Improve support for Unicode characters in identifiers
<https://github.com/sg16-unicode/sg16/issues/56>
Tom.
> Sincerely,
> JeanHeyd
> Dear SG16 and C/C++ Liaison Group,
>
> N2594 - https://thephd.github.io/_vendor/future_cxx/papers/C%20-%20Mixed%20Wide%20String%20Literal%20Concatenation.html
> - was accepted by WG14 this meeting and we just adjourned. This means
> both languages have feature parity in this regards! 🎉
Excellent! Nice work!
>
> BUT!
>
> WG14 also wants to look into -- after removing it -- spending
> some time coming up with well-defined combination mechanism. We would
> like to have ill-formedness (C++) / constraint violations (C) if the
> conversion to the final chosen encoding do not work, to give people
> good guarantees above e.g. synthesizing Unicode into an wide string
> literal or synthesizing wide string data into Unicode literals.
Was any particular use case discussed? Or just a general preference to,
given something like this:
#define NAME u8"foo"
#define VERSION "5"
void emit(const char16_t*);
to be able to do something like this:
emit(u"" NAME "-" VERSION);
as opposed to having to do conversions and concatenations at run-time?
>
> (Also, I forgot to ask if they wanted to do something similar to
> P1041 - https://wg21.link/p1041 - yet...)
That would be good to get on the agenda for the next WG14 meeting. It
would be great if we can start making progress on all of the following
issues! My understanding is that any proposals targeting C2X must be
proposed by August 27th, 2021.
* WG14: Make char16_t/char32_t string literals be UTF-16/32
<https://github.com/sg16-unicode/sg16/issues/54>
* WG14 N2231: char8_t: A type for UTF-8 characters and strings
<https://github.com/sg16-unicode/sg16/issues/5>
* WG14: Improve support for Unicode characters in identifiers
<https://github.com/sg16-unicode/sg16/issues/56>
Tom.
> Sincerely,
> JeanHeyd
Received on 2020-12-06 16:41:04