Is there a reason why
char::is_ascii_hexdigit exist, whereas there is no shorthand to check if a character is a valid octal? While it is as simple as
matches!(c, '0'..='7'), I would prefer to have the proposed API because:
- it is a lot more ergonomic in point-free form, i.e.:
my_string.chars().filter(char::is_ascii_octdigit) as compared to
my_string.chars().filter(|c| matches!(c, '0'..='7')) or
- the intent is a lot more obvious
- completeness, I just think it fills a gap(?) in the list of
c.is_digit(8) whose intent is perhaps a little more obvious than using explicit ranges.
And if the libs API is to be expanded, it should probably now use const generics to be more general eg
fn is_digit_const<const BASE: u32>(self) -> bool which could then be invoked in "point-free" form as eg
I’m curious what you’re using octal for in 2022!
Can't speak for the OP, but
chmod for example still takes octal here in the year 03746.
I've used it when parsing
git ls-tree output.
I myself happened to use it earlier today to represent bit lengths, because the second position onward represent the number of bytes and the units represent offset into the final byte.
Yeah octal is perfect for thinking about memory.
On x86-64 linux, in octal:
1 byte = 10 bits
1 machine word = 100 bits
1 cache line = 1000 bits
1 page = 100000 bits
1 huge page = 100000000 bits
1 huger page = 100000000000 bits
as @quinedot mentioned, i realized this method was not present when i was validating a string containing file permissions!
I would be happy to merge a PR adding this method (as unstable, with a tracking issue). As several people in this thread observed, it does still come up in the context of file modes.
thanks, i'd love to give that a shot!
It would be great to have both a const generic version and
char::is_ascii_octdigit as a special case since it's so useful.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.