Subject: Re: Reminder: SG16 telecon tomorrow (Wednesday, 2020-06-10)
From: Tom Honermann (tom_at_[hidden])
Date: 2020-06-10 13:51:11
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
> 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
> 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.
> 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
> 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.
SG16 list run by email@example.com