On 3/17/21 5:23 AM, Corentin Jabot wrote:


On Tue, Mar 16, 2021 at 3:59 PM Tom Honermann via SG16 <sg16@lists.isocpp.org> wrote:

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

For participants in North America, please note that daylight savings time went into effect this past weekend, so this telecon will start one hour later than our last telecon (Mexico doesn't observe DST until April 4th).

The agenda is:

For D2314R1 and D2297R1, discussion will be limited to new information that might help to break the stalemate regarding use of an abstract character set or UCS scalar values as the specification tool for describing translation.  If consensus is not reached, we'll poll forwarding D2314R1 with direction that EWG and/or CWG choose the wording mechanism.

Per P1000, papers targeting C++23 must be forwarded by EWG/LEWG to CWG/LWG by the February, 2022 meeting (Portland).  However, the deadline for initial papers proposing new language features is ~November, 2021.  Time is running short, and competition for time in EWG/LEWG will increase.

The following lists the current state of SG16 related papers and our C++23 effort to date.  This is presented as food for thought.  What story does this tell?  How will that story be received by the C++ community?  What should we do with our remaining time to either strengthen or change that story?  What can we realistically do to bring more direct benefits to the C++ community?  It may be interesting to review what we were thinking about during our March 13th, 2019 telecon.

These papers have been accepted for C++23:

  • P2029: Proposed resolution for core issues 411, 1656, and 2333; numeric and universal character escapes in character and string literals

These papers have been approved by EWG and are in the pipeline for CWG:

  • P1949: C++ Identifier Syntax using Unicode Standard Annex 31
  • P2201: Mixed string literal concatenation
  • P2223: Trimming whitespaces before line splicing

These papers have been approved by SG16 and are in the pipeline for EWG/LEWG:

  • P1885: Naming Text Encodings to Demystify Them
  • P2093: Formatted output
  • P2246: Character encoding of diagnostic text
  • P2316: Consistent character literal encoding

These papers are in the pipeline for EWG/LEWG, but require a revision to make progress:

  • P2071: Named universal character escapes

I would like us to make progress on that! Afaik there isn't a lot of work remaining, right?

I need to review notes, but from what I remember, only minor updates are needed to the paper; doing that is on my plate and it is realistic that I could get to it soon.

Implementing it in a compiler would help to reduce some concerns.  I'm afraid I won't have time to do that for a while though.

 

These papers are currently active in SG16:

  • D2314R1: Character sets and encodings
  • D2297R1: Wording improvements for encodings and character sets

With that summary of what we have been doing above in mind, the following lists provide some options for what we could work on next.

These are existing papers available for SG16 to prioritize: (Some of these, such as P1629, are awaiting revisions).

  • P1628: Unicode character properties
As the author I do not expect to do further work on this in the 23 cycle
That matches my expectations, thanks for confirming.
  • P1629: Standard Text Encoding
  • P1729: Text Parsing
  • P1859: Standard terminology for execution character set encodings
This is mostly superseded by 2314/2297 - we should make sure the direction are consistent
 
  • P1953: Unicode Identifiers And Reflection
This is ending progress in SG-7

That isn't the effect I would expect this paper to have on SG-7. "pending" on the other hand... ;)

 
  • P2295: Correct UTF-8 handling during phase 1 of translation
Expect a revision of that soon

And finally, here are some ideas that have been discussed, but that we do not currently have papers covering:

  • UTF-8 as a portable source file encoding (the paper Tom started and has long intended to complete).
See also P2295
Yes, clearly related.
I had started a paper on this a while back.  Yet another unfinished paper.  I'd like to see this done, but it will have no meaningful impact to the C++ community, so we should consider that when prioritizing.

I agree, and providing this would be useful for the story we tell, but I suspect won't impact actual adoption.

Tom.