Repository navigation
Tracking issue for making ASCII ctype inherent methods const fn #68983
Description
This is a tracking issue for making the inherent methods introduced in #46077 into const fn. This includes all functions listed in #39658 for both u8 and char, namely:
is_ascii_alphabeticis_ascii_uppercaseis_ascii_lowercaseis_ascii_alphanumericis_ascii_digitis_ascii_hexdigitis_ascii_punctuationis_ascii_graphicis_ascii_whitespaceis_ascii_control
The feature gate for the const version of these functions is #![feature(const_ascii_ctype_on_intrinsics)]. These cannot be const-stabilized until #![feature(const_if_match)] is stable.
Activity
[-]Tracking issue for making ASCII character type methods on intrinsics[/-][+]Tracking issue for making ASCII ctype inherent methods `const fn`[/+]Rollup merge of rust-lang#68986 - ecstatic-morse:const-ascii-ctype, r…
Demi-Marie commentedon Apr 15, 2020
Could these be implemented by means of a lookup table?
ecstatic-morse commentedon May 14, 2020
@demimarie-parity Sorry I missed your comment.
They could be, although the generated code would likely be worse than the branchy version.
#![feature(const_if_match)]is close to being stabilized (see #49146), so I would prefer to wait until that occurs. If it is delayed for some reason, we could revisit.Demi-Marie commentedon May 14, 2020
@ecstatic-morse my experience in practice (albeit in Haskell) has been the opposite ― the lookup table is significantly faster.
ecstatic-morse commentedon May 14, 2020
You're welcome to try it out. If it is indeed faster, that would be a valuable addition to the standard library. I will point out that the obvious microbenchmark will put the lookup table in the L1 cache, so it won't be fair unless you're calling these functions in a tight loop. Perhaps that's the most common mode of use and we should indeed be optimizing for it?
Demi-Marie commentedon May 14, 2020
My tests were done several years ago, and indeed involved calling these functions in a tight loop. I have no idea if that is the most common use, though.
ecstatic-morse commentedon May 14, 2020
I think if you were able to demonstrate that a lookup table based approach was faster in rust in a tight loop, the libs team would seriously consider switching to it. I'm not on the libs team, so I don't know how they evaluate time/memory trade-offs such as this one.
If you have any questions about writing microbenchmarks in rust, I'm happy to answer them. If you're not interested, consider opening an issue so someone else can look into it. I think it's an idea that's worth testing.
m-ou-se commentedon Sep 22, 2021
Looks like these were already stabilized as const in 1.47. Closing this issue.