With respect to P1859:
-Basic source character set
-: The abstract characters that must be representable in the _character set_ used for source code
+Source character set
+: The abstract characters that must be representable in the internal _character set_ used after phase 1 of translation. All characters not in the source character set are converted to universal-character-names, which are made up of characters from the basic character set. The abstract parser only sees characters in the source character set.

There is no "Basic" source character set. There is the character set the lexer and parser uses that is available after the implementation defined conversion from whatever was presented as source. 
I don't think anyone understands that, outside CWG. 
Having more precision around the values emitted into narrow, wide, and uN literals from the execution character set, and what happens when that fails I still believe would be useful.

Perhaps for 26 we could rewrite entirely in terms of processing code points and occasionally "orginal spelling". It would be nice if the logical model was closer to what the physical model is. 


On Tue, May 26, 2020 at 1:37 PM Tom Honermann via SG16 <sg16@lists.isocpp.org> wrote:

This is your friendly reminder that an SG16 telecon will be held tomorrow, Wednesday May 27th, at 19:30 UTC (timezone conversion).  To attend, visit https://bluejeans.com/140274541 at the start of the meeting.

Steve will circulate a draft revision of P1949 on the SG16 mailing list today.

The agenda for the meeting is:

  • D1949R4: C++ Identifier Syntax using Unicode Standard Annex 31
    • Review updates since the April 22nd review.
  • Discuss terminology updates to strive for in C++23

Anticipated decisions to be made at this meeting include:

  • Whether to forward the new draft revision of P1949 to EWG.

Prior to tomorrow's meeting, please:

  • review Steve's draft revision.
  • review P1859R0, particularly the proposed terminology.
  • think of other terminology changes to be considered.
  • think of how we can divide up the work for making terminology updates.

Tom.

--
SG16 mailing list
SG16@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16