On Wed, Jun 10, 2020, 19:28 Hubert Tong via SG16 <sg16@lists.isocpp.org> wrote:
On Tue, Jun 9, 2020 at 10:48 AM Tom Honermann via SG16 <sg16@lists.isocpp.org> 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:

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 would like to see that gone entirely ultimately

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.

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.

I don't think we intend to remove the restrictions from where they are!


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.

This is one of the reason why we need to separate character set and character encoding.
I think the expectation is that the code units size of the execution character set is <= sizeof(char)

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.

We should because it is incorrect and we need to separate the core language, which has an implementation defined mechanism to decide which encoding use, which may or may not depend on locale, and the way which there are interpreted by library - which is currently always either locale dependant or encoding agnostic.
A note to explain the relation would be useful though



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.

Can you clarify that please?
Although we have some concensus we should copy the definitions we want to use in the standard to avoid too much cross references, and keep the standard somewhat self contained