My notes indicate that it's narrative text about the implications and consequences for putting the three characters into the set. I can have that.  I don't think we found wording changes.

Yes, that sounds correct.

I'm working to get the minutes from the meeting published today (my apologies for being so delinquent again). A draft of the P2558R0 discussion follows.

Steve, assuming it is realistic for you to have an updated paper for the meeting tomorrow, could you 1) cross check your updates with the requests below, and 2) reply to this thread with an updated draft/revision once you have one available.

• P2558R0: Add @, $, and ` to the basic character set

  • PBrett asked whether this proposal is an SG16 concern.
  • Tom replied that we are the encoding experts and best equipped within the committee to evaluate whether these changes will have consequences for source character sets used in practice; our affirmation of the proposal will hopefully ease progress through other groups.
  • Charlie asked for confirmation that SG22 will review the paper as well.
  • Steve replied affirmatively and stated WG14 has already adopted the proposal for C.
  • Someone (apologies, the editor neglected to record who) noted the existence of P2342: For a Few Punctuators More and that it argues that these characters could be used as new operators.
  • Tom responded that P2342 is an example of a paper that is not an SG16 concern; once the characters are available in the source character set, how they are used is an EWG concern.
  • Hubert observed that this introduces a requirement that these characters be encoded as a single code unit.
  • Jens acknowledged and noted that this is required by [lex.charset]p6 for all characters in the basic literal character set.
  • Jens requested that the paper prose discuss this requirement.
  • Steve agreed to add such prose.
  • Jens stated that he does not know if this requirement would be problematic for any existing character sets.
  • Steve replied that there are infrequently used EBCDIC code pages that lack them.
  • Jens asked if those code pages also lack other characters.
  • Steve responded that the probably do.
  • Charlie asked if those problematic EBCDIC code pages have unused code points that could be used for these characters.
  • Tom suggested that digraphs could be introduced to support those code pages if needed.
  • Jens replied that digraphs can't be used inside character or string literals.
  • Steve suggested this concern can be addressed if these characters start getting used within the standard.
  • Jens reported that the addition of these characters to the basic character set makes them ineligible to be specified via a universal-character-name (UCN) outside of a character or string literal due to [lex.charset]p3.
  • PBrett suggested that restriction could be lifted.
  • Charlie stated that existing uses of '$' are probably limited to identifiers and symbol renaming via attributes, pragma directives, or asm labels.
  • Hubert reported they may appear in preprocessor stringization.
  • PBrett reported they may appear in header names as well.
  • Jens noticed that use of a UCN to#include a source file named with one of these characters would become ill-formed.
  • PBrett reiterated support for lifting restrictions on use of UCNs to name characters from the basic character set with the rationale that we shouldn't ban things that are only bad ideas.
  • Charlie stated that, if such incompatibilities were to cause problems in practice, then ifting that restriction would be the obvious solution.
  • Steve suggested such concerns can be addressed after the paper is approved; we know programmers want to use these characters.
  • Tom asked Steve if he knows whether the UCN concern was discussed in WG14.
  • Steve replied that it was not.
  • Hubert asked when UCNs are translated in identifiers and other preprocessor tokens.
  • Jens replied, during translation phase 3 except in quoted contexts; so translation occurs as a preprocessing-token is formed.
  • PBrett observed that the new UCN restrictions would be limited to h-char and q-char sequences since these characters aren't otherwise usable outside quoted contexts.
  • Jens replied that they may also appear in a preprocessing-token used in stringization.
  • Hubert stated that a UCN specifying one of these characters would become ill-formed during stringization.
  • Hubert added that, likewise, use of a UCN to specify '$' in an identfier would become ill-formed.
  • Tom asked whether that matters since use of '$' in an identifier is already an extension.
  • Jens noted that these characters currently match the "each non-whitespace character that cannot be one of the above" case of preprocessing-token.
  • Jens stated that this makes such intended use in identifiers ill-formed since, after this change, such a character would appear as a lone preprocessing-token.
  • [ Editor's note: This behavior doesn't seem related to the proposed change since, previously, a UCN naming one of these characters would also appear as lone preprocessing-token. The editor is concerned that this portion of the discussion was not captured accurately. ]
  • Jens requested that this discussion be included in the paper.
  • PBrett asked whether h-char and q-char sequences remain a backward compatibility concern.
  • Jens replied that they do, but that UCNs in such sequneces already have implementation-defined behavior; what UCNs mean in h-char and q-char sequences isn't really defined.
  • [ Editor's note: Per [lex.phases]p1.3, UCNs are not recognized and replaced in h-char-sequence and q-char-sequence sequences and, per [lex.header]p1, these sequences are mapped in an implementation-defined manner. ]
  • Tom suggested that it might be worth updating the paper to describe how existing implementations behave with respect to UCNs in preprocessor stringization and #include directives.
  • Jens asked if there are other ways in which these characters might plausibly be used today.
  • Tom replied that Objective-C uses '@'.
  • Jens raised the possibility of concerns regarding imposing single code unit encoding for these characters on the execution character set.
  • Tom asked Hubert if he was aware of any EBCDIC related concerns.
  • Hubert replied that his colleagues in WG14 did not express such concerns and that he is confident that they would have if they had any.
  • Hubert noted that locales that don't support these characters would no longer be strictly conforming but could still be supported as extensions.
  • Tom summarized the discussion; there are requests to Steve to update the prose for several of the items discussed, but that there do not appear to be any objections to the paper direction.

Tom.

On Sat, Apr 23, 2022, 09:04 Tom Honermann via SG16 <sg16@lists.isocpp.org> wrote:

SG16 will hold a telecon on Wednesday, April 27th, at 19:30 UTC (timezone conversion).

The agenda is:http://eel.is/c++draft/lex.header#1

• P2286R7: Formatting Ranges
• Review recent updates and confirm direction.
  
• (The link is to a draft revision attached to the LWG wiki page)
  
• P2558R0: Add @, $, and ` to the basic character set
• Continue review pending the availability of an updated revision.
  
• D2572R0: std::format() fill character allowances
• Continue review pending the availability of an updated revision.

LWG has tentatively approved P2286R7 as linked above pending SG16 confirmation of design intent and wording for non-Unicode encodings. Please review the SG16 2022-01-26 meeting summary for previously discussed concerns. A few wording details are still being discussed outside of the mailing lists, so the paper revision linked above may still receive some updates prior to our meeting.

Further review of P2558R0 and D2572R0 are scheduled pending updates from the authors to address feedback from the SG16 2022-04-13 telecon (which I have yet to publish).

Tom.

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