Changing the name from is_ascii_* to ascii_is_* will also work similarly to
clarify. In this case, the interpretation (with "ascii" at the front) is
that the input is assumed to be "ASCII-compatible".

I am afraid ascii_is_* may invite LEWG to change the names to be is_ascii_*
though.

-- HT

On Wed, Sep 24, 2025 at 3:07 PM Hubert Tong <
hubert.reinterpretcast_at_[hidden]> wrote:

> On Wed, Sep 24, 2025 at 2:01 PM Jan Schultke <janschultke_at_[hidden]>
> wrote:
>
>> > 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?
>>
>
> Because "ascii" as an adjective in the name is ambiguous. It can be taken
> to mean that it restricts the domain of abstract characters to the ones
> encoded by US-ASCII.
> Adding "data_" says that the function operates on the numerical value.
>
> -- HT
>