On 6/10/20 1:28 PM, Hubert Tong wrote:
> On Tue, Jun 9, 2020 at 10:48 AM Tom Honermann via SG16
> <sg16_at_[hidden] <mailto:sg16_at_[hidden]>> wrote:
>
> This is your friendly reminder that an SG16 telecon will be held
> tomorrow, Wednesday June 10th, at 19:30 UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20200610T193000&p1=1440>).
> To attend, visit https://bluejeans.com/140274541 at the start of
> the meeting.
>
> The agenda for the meeting is:
>
> * Discuss terminology updates to strive for in C++23
> o P1859R0: Standard terminology character sets and encodings
> <https://wg21.link/p1859>
> o Establish priorities for terms to address.
> o Establish a methodology for drafting wording updates.
>
> This may be useful for an intermediate stage of the process of
> updating the wording:
>
> Basic source character set:
> set of abstract characters used for the description of source code for
> the purposes of this document
>
> I think the "basic source character set" fails to be a "character
> set". I believe the elements of a character set are mappings of values
> to abstract characters.

I agree with your characterization of a "character set". But, the
members of the "basic source character set" arguably have values on an
implementation-defined basis. Per [cpp.cond]p12
<http://eel.is/c++draft/cpp.cond#12>, the values of character literals
used in a conditional preprocessing directive may have values different
from their values in the execution character set; and if they don't
correspond to the values of the basic source character set members, then
I don't know what else they might correspond to. This may be indicative
of the existence of an additional, currently unnamed,
conditionally-defined character set.

Tom.

>
> re: Basic execution character set: I believe that these characters
> have some restrictions on their values and encoding. It would help to
> call these out with a note to the definition.
>
> re: Execution character set: I have qualms about claiming
> representability of these in a char character literal. The term is
> intended to encompass abstract characters whose encoding is multibyte.
>
> re: 3.1.2: You mean wchar_t?
>
> re: wording, we should not remove the indication that the
> interpretation of character or string data is affected by locales.
>
> The paper is not clear that the definitions section is intended to be
> considered wording. From a procedural point of view, this is a serious
> problem.
>
> The terms should come from the ISO/IEC 10646 definition. The Unicode
> definitions fail to meet drafting requirements from the ISO/IEC
> Directives, Part 2.