This meeting is starting now. Well, subject to more attendees, it's just
Steve and I hanging out right now!

Tom.

On 9/24/25 2:04 AM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting *today*, Wednesday, September 24th, at 19:30
> UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20250924T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>
> If you need a .ics file to import into your calendar, you can download
> it here
> <https://documents.isocpp.org/remote.php/dav/public-calendars/R7imgS2LJD9xfeWN/BD8B73CA-A2A2-45E0-A9AB-2946907DF646.ics?export>.
>
> The agenda is:
>
> * P3688R3: ASCII character utilities <https://wg21.link/p3688r3>.
> * P3733R0: More named universal character escapes
> <https://wg21.link/p3733r0>.
> * P3695R1: Deprecate implicit conversions between Unicode character
> types <https://wg21.link/p3695r1>.
>
> All three papers come to us courtesy of Jan Schultke with Corentin as
> a co-author of the first. None of these papers have been previously
> reviewed by SG16. I don't expect that we'll get through all three.
>
> *P3688R3* seeks to provide a suite of utility functions specialized
> for working with ASCII text or the ASCII subset of Unicode text.
> Predicates for querying character properties, transformers for case
> conversions, and case insensitive comparators are provided. As always,
> encoding related design choices are present and I'm sure we'll have
> some fun talking about that.
>
> *P3733R0* proposes extending the set of character names available for
> use in named character escapes to include ones for which we didn't
> have a normative reference available back when P2071R2 (Named
> universal character escapes) <https://wg21.link/p2071r2> was approved
> for C++23. This include popular short names like NBSP and ZWJ.
>
> *P3695R1* is sure to be the most fun of the bunch! It asks to
> deprecate implicit conversions between char8_t and the other char/N/_t
> types so that oopsies like c8==U'🙊' (where c8 is char8_t) can be
> diagnosed. Per section 3.2, the proposal includes rationale for _not_
> extending similar deprecation to char16_t; thus the proposal will not
> solicit a diagnostic for the always false c16==U'🙊' (where c16 is
> char16_t).
>
> Tom.
>
>
>