Why are these ASCII methods inconsistent? - ascii

Question

When I look at the rust ASCII operations it feels like there is a consistency issue between
is_lowercase/is_uppercase:
pub fn is_uppercase(&self) -> bool {
(self.chr - b'A') < 26
}
is_alphabetic:
pub fn is_alphabetic(&self) -> bool {
(self.chr >= 0x41 && self.chr <= 0x5A) || (self.chr >= 0x61 && self.chr <= 0x7A)
}
Is there a good reason? Are the two methods totally equivalent or am I missing something?
All these functions are marked as stable so I'm confused.
EDIT:
To make it clearer, what I would expect is to decide on the best (in terms of performance/readability/common practice) implementation for lower/upper then have
pub fn is_alphabetic(&self) -> bool {
self.is_lowercase() || self.is_uppercase()
}

Answer 1

Since the question changed to be about performance, I'll add a second answer.
To start, I created a clone of the Ascii module (playpen):
pub struct Alpha(u8);
impl Alpha {
#[inline(never)]
pub fn is_uppercase_sub(&self) -> bool {
(self.0 - b'A') < 26
}
#[inline(never)]
pub fn is_uppercase_range(&self) -> bool {
self.0 >= 0x41 && self.0 <= 0x5A
}
}
fn main() {
let yes = Alpha(b'A');
let no = Alpha(b'a');
println!("{}, {}", yes.is_uppercase_sub(), yes.is_uppercase_range());
}
In the playpen, make sure that the optimization is set to -O2 and then click IR. This shows the LLVM Intermediate Representation. It's like a higher-level assembly, if you'd like.
There's lots of output, but look for the sections with fastcc. I've removed various bits to make this code clearer, but you can see that the exact same function is called, even though our code calls two different implementations, one with a subtraction and one with a range:
%3 = call fastcc zeroext i1 #_ZN5Alpha16is_uppercase_sub20h63aa0b11479803f4laaE
%5 = call fastcc zeroext i1 #_ZN5Alpha16is_uppercase_sub20h63aa0b11479803f4laaE
The LLVM optimizer can tell that these implementations are the same, so really it's up to the developers preference. You might be able to get a commit into Rust to make them consistent, if you'd like! ^_^
Asking about is_alphabetic is harder; inlining will come into play here. If LLVM inlines is_upper and is_lower into is_alphabetic, then your suggested change would be better. If it doesn't, then potentially what was 1 function call is now 3! That could be really bad.
These types of questions are a lot harder to answer at this level; one would have to do some looking (edit and profiling!) at real Rust code in the large to understand the optimizer with regards to inlining.

Answer 2

They're equivalent. is_alphabetic could be written with byte literals instead of hex codes, making it more readable and matching the other functions:
pub fn is_alphabetic(&self) -> bool {
(self.chr >= b'A' && self.chr <= b'Z') ||
(self.chr >= b'a' && self.chr <= b'z')
}

Answer 3

The values in is_alphabetic certainly correspond to the appropriate ASCII values for the letters. You can validate this with:
println!("0x{:x} 0x{:x}", b'A', b'A');
println!("0x{:x} 0x{:x}", b'a', b'z');
is_alphabetic relies on the fact that the ASCII lower and uppercase letters are sequential (not with each other, unfortunately). It could have been written:
pub fn is_alphabetic(&self) -> bool {
(self.chr >= b'A' && self.chr <= b'Z') || (self.chr >= b'a' && self.chr <= b'z')
}
// Or
pub fn is_alphabetic(&self) -> bool {
self.is_upper() || self.is_lower()
}
is_lower and is_upper both rely on unsigned math underflow to be correct. If a is 0x61 and z is 0x7A, and we subtract a from both, we get 0 and 25. However, if it's one less than a, we would get 0xFF. 0xFF is not < 26, so it will fail that check.