Date: Wed, 8 Jul 2020 11:43:36 +0100
Minor nit: I dislike normatively stating that a null character is
appended after string concatenation in two places. I do like
the addition of this directly to the phase 6 wording, so suggest
that the original in [lex.string]p12 with its extra flowery language
be demoted to a note.
In the normative text, AFAICT, in C++20 wide multi character
literals must be supported, with an implementation-defined value,
but after this paper they will be conditionally supported. I don’t
see that design change addressed in the front matter. Same
applies to non-encodable wide characters .
(I thought this also applied to ordinary multi character literals,
but it turns out they are already conditionally supported.)
AlisdairM
> On Jul 7, 2020, at 16:33, Tom Honermann via Core <core_at_[hidden]> wrote:
>
> An update of D2029R2 (Proposed resolution for core issues 411, 1656, and 2333; numeric and universal character escapes in character and string literals) is now available at https://rawgit.com/sg16-unicode/sg16/master/papers/d2029r2.html. This addresses the feedback provided on the core mailing list in the thread starting at https://lists.isocpp.org/core/2020/06/9455.php.
>
> Wording review feedback prior to the next Core issues processing teleconference would be much appreciated!
>
> Tom.
>
> _______________________________________________
> Core mailing list
> Core_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post: http://lists.isocpp.org/core/2020/07/9545.php
appended after string concatenation in two places. I do like
the addition of this directly to the phase 6 wording, so suggest
that the original in [lex.string]p12 with its extra flowery language
be demoted to a note.
In the normative text, AFAICT, in C++20 wide multi character
literals must be supported, with an implementation-defined value,
but after this paper they will be conditionally supported. I don’t
see that design change addressed in the front matter. Same
applies to non-encodable wide characters .
(I thought this also applied to ordinary multi character literals,
but it turns out they are already conditionally supported.)
AlisdairM
> On Jul 7, 2020, at 16:33, Tom Honermann via Core <core_at_[hidden]> wrote:
>
> An update of D2029R2 (Proposed resolution for core issues 411, 1656, and 2333; numeric and universal character escapes in character and string literals) is now available at https://rawgit.com/sg16-unicode/sg16/master/papers/d2029r2.html. This addresses the feedback provided on the core mailing list in the thread starting at https://lists.isocpp.org/core/2020/06/9455.php.
>
> Wording review feedback prior to the next Core issues processing teleconference would be much appreciated!
>
> Tom.
>
> _______________________________________________
> Core mailing list
> Core_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post: http://lists.isocpp.org/core/2020/07/9545.php
Received on 2020-07-08 05:46:54