On Wed, Sep 24, 2025 at 12:47 PM Jan Schultke <janschultke_at_[hidden]>
wrote:

> Hubert,
>
> What interface are you suggesting as an alternative then? Should these
> functions not take char as an input or what?
>

I think having the query functions named data_is_ascii_* may be sufficient
to alleviate these concerns.

-- HT


>
> On Wed, Sep 24, 2025, 18:36 Hubert Tong <hubert.reinterpretcast_at_[hidden]>
> wrote:
>
>> On Wed, Sep 24, 2025 at 2:04 AM Tom Honermann via SG16 <
>> sg16_at_[hidden]> 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>.
>>>
>>> I am quite concerned with the paper. I find the `is_ascii_` naming to be
>> semantically confusing. For especially the `char` overloads (and to a
>> lesser extent, the `wchar_t` overloads), I feel that the paper proposes
>> data-centric treatment and that the "text" interface is incongruous.
>>
>> -- HT
>>
>>>
>>> -
>>> - 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.
>>>
>>>
>>> --
>>> SG16 mailing list
>>> SG16_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>> Link to this post: http://lists.isocpp.org/sg16/2025/09/4614.php
>>>
>>