Repository navigation
Tracking Issue for {char, u8}::is_ascii_octdigit #101288
Description
Feature gate: #![feature(is_ascii_octdigit)]
This is a tracking issue for two new methods char::is_ascii_octdigit and u8::is_ascii_octdigit, which, in the same vein as is_ascii_hexdigit, checks if a value is an ASCII octal digit ('0'..='7').
This is a shorthand for {char, u8}::is_digit(self, 8). Prior discussion on irlo.
Public API
// core::char
impl char {
pub fn is_ascii_octdigit(self) -> bool;
}
// core::num
impl u8 {
pub fn is_ascii_octdigit(self) -> bool;
}Steps / History
- Implementation: introduce
{char, u8}::is_ascii_octdigit#101308 - Final comment period (FCP)1
- Stabilization PR
Unresolved Questions
- None yet.
Footnotes
Reacted by Gabriel Bjørnager Jensen
Reacted by Gabriel Bjørnager Jensen
Activity
oppiliappan commentedon Sep 1, 2022
@rustbot claim
oppiliappan commentedon Sep 2, 2022
This method is also applicable to bytes, so the scope of this issue extends to
u8as well.[-]Tracking Issue for `char::is_ascii_octdigit`[/-][+]Tracking Issue for `{char, u8}::is_ascii_octdigit`[/+]DaniPopes commentedon Sep 28, 2023
This has been unstable for more than a year, and since there are no reported issues or blockers I think this can be stabilized.
The full API is this (note the
&selfandconst):joshtriplett commentedon Oct 5, 2023
Shall we stabilize is_ascii_octdigit?
@rfcbot merge
rfcbot commentedon Oct 5, 2023
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
Concerns:
{char, u8}::is_ascii_octdigit#101288 (comment))Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
workingjubilee commentedon Oct 10, 2023
Every function we add comes at the cost of making it harder to find others, and u8 already has a very heavily-loaded API. I am concerned this doesn't pull its weight. Many new Rust programmers often flail for some time while looking for basic functions. In the past week I've had to coach people on locating basic things like
str::find.BurntSushi commentedon Oct 10, 2023
@rfcbot concern does not pull its weight
I'll file this concern because I'm not totally sold on this method either, but I lean towards including it. It fits right in with existing methods. With that said, octal notation is in my experience way less frequently used than either decimal or hexadecimal, so I'm not sold that it's worth adding a method specifically for it.
We have at least a few examples where we load up types with lots of different methods, so I tend to think we should try to approach that problem in other ways. For example, improving rustdoc output. I am a casual user of separating methods into different groups based on categories that I think might be useful to others. Of course, one of the issues with this approach is that grouping is also somewhat determined by trait bounds, so this could overall be somewhat confusing given the status quo of rustdoc.
m-ou-se commentedon Nov 7, 2023
I'm also not convinced this method is worth adding. (Would we also add
is_ascii_bindigit()too?)On
char, this funcitonality is already available as.is_digit(8)(and.to_digit(8).is_some()).dtolnay commentedon Jan 1, 2024
+1 to the feeling that
is_ascii_octdigitdoes not pull its weight as a dedicated API onu8andchar.For
charthis is served plenty well enough by.is_digit(8)as Mara wrote.What's the counterproposal for
u8? Is it this?—dtolnay commentedon Jan 16, 2024
From the last couple comments, I get the sense this is not going to go through.
@rfcbot fcp cancel
rfcbot commentedon Jan 16, 2024
@dtolnay proposal cancelled.