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

In general, I understand that it's a bit odd to have something like
is_ascii_digit('0') be potentially false and run a purely numerical
test that ignores literal encoding, but every alternative seems worse
here. I don't feel like saying "data_is_ascii_digit('0')" meaningfully
improves this.

We also usually say "lerp" or "midpoint", not "numbers_lerp"; adding
"data_" to the name feels like it repeats information that is evident
from the parameter. Isn't a char a datum? Why would we need to say
"data_", as if that added any sort of information?

> -- 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).
>>>>
>>>> If you need a .ics file to import into your calendar, you can download it here.
>>>>
>>>> The agenda is:
>>>>
>>>> P3688R3: ASCII character utilities.
>>>
>>> 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.
>>>> P3695R1: Deprecate implicit conversions between Unicode character types.
>>>>
>>>> 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) 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 charN_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