Tracking Issue for {char, u8}::is_ascii_octdigit

[oppiliappan]

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)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[oppiliappan]

@rustbot claim

[oppiliappan]

This method is also applicable to bytes, so the scope of this issue extends to u8 as well.

[DaniPopes]

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 &self and const):

impl {char,u8} {
    pub const fn is_ascii_octdigit(&self) -> bool;
}

[joshtriplett]

Shall we stabilize is_ascii_octdigit?

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

Concerns:

• does not pull its weight (Tracking Issue for {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]

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]

@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]

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]

+1 to the feeling that is_ascii_octdigit does not pull its weight as a dedicated API on u8 and char.

For char this is served plenty well enough by .is_digit(8) as Mara wrote.

What's the counterproposal for u8? Is it this?—

let byte = b'7';
println!("{}", (byte as char).is_digit(8));

[dtolnay]

From the last couple comments, I get the sense this is not going to go through.

@rfcbot fcp cancel

[rfcbot]

@dtolnay proposal cancelled.