Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for making ASCII ctype inherent methods const fn #68983

Closed
ecstatic-morse opened this issue Feb 9, 2020 · 7 comments
Closed
Labels
A-const-fn Area: const fn foo(..) {..}. Pure functions which can be applied at compile time. A-slice Area: [T] A-str Area: str and String B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. Libs-Tracked Libs issues that are tracked on the team's project board. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@ecstatic-morse
Copy link
Contributor

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_alphabetic
  • is_ascii_uppercase
  • is_ascii_lowercase
  • is_ascii_alphanumeric
  • is_ascii_digit
  • is_ascii_hexdigit
  • is_ascii_punctuation
  • is_ascii_graphic
  • is_ascii_whitespace
  • is_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.

@ecstatic-morse ecstatic-morse added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Feb 9, 2020
@ecstatic-morse ecstatic-morse changed the title Tracking issue for making ASCII character type methods on intrinsics Tracking issue for making ASCII ctype inherent methods const fn Feb 9, 2020
@jonas-schievink jonas-schievink added A-const-fn Area: const fn foo(..) {..}. Pure functions which can be applied at compile time. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. B-unstable Blocker: Implemented in the nightly compiler and unstable. F-const_if_match labels Feb 9, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Feb 10, 2020
…=Centril

Make ASCII ctype functions unstably const

Makes the following inherent methods on `u8` and `char` unstable `const fn`:

 * `is_ascii_alphabetic`
 * `is_ascii_uppercase`
 * `is_ascii_lowercase`
 * `is_ascii_alphanumeric`
 * `is_ascii_digit`
 * `is_ascii_hexdigit`
 * `is_ascii_punctuation`
 * `is_ascii_graphic`
 * `is_ascii_whitespace`
 * `is_ascii_control`

cc rust-lang#68983
@Demi-Marie
Copy link

Could these be implemented by means of a lookup table?

@ecstatic-morse
Copy link
Contributor Author

@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
Copy link

@ecstatic-morse my experience in practice (albeit in Haskell) has been the opposite ― the lookup table is significantly faster.

@ecstatic-morse
Copy link
Contributor Author

ecstatic-morse commented 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
Copy link

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
Copy link
Contributor Author

ecstatic-morse commented 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.

@KodrAus KodrAus added A-slice Area: [T] A-str Area: str and String Libs-Tracked Libs issues that are tracked on the team's project board. labels Jul 29, 2020
@m-ou-se
Copy link
Member

m-ou-se commented Sep 22, 2021

Looks like these were already stabilized as const in 1.47. Closing this issue.

@m-ou-se m-ou-se closed this as completed Sep 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-fn Area: const fn foo(..) {..}. Pure functions which can be applied at compile time. A-slice Area: [T] A-str Area: str and String B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. Libs-Tracked Libs issues that are tracked on the team's project board. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants