I'm pretty sure rust uses usize, which is 64 bits on modern architectures.
#![feature(type_name_of_val)]
fn main() {
let v = vec![1, 2, 3];
let x = 1;
let y = 1;
v[x];
dbg!(std::any::type_name_of_val(&x));
dbg!(std::any::type_name_of_val(&y));
}
[src/main.rs:11] std::any::type_name_of_val(&x) = "usize"
[src/main.rs:12] std::any::type_name_of_val(&y) = "i32"
v[y];
It looks to me like when the types are ambiguous (because nothing placed a restriction on them), integer literals become 32 bit and floating literals become 64 bit. Then quietly, later when you add a restriction, the code above (which you've already worked through one line at a time with debug statements and all) changes from underneath you.
> You can still declare types ahead of time if you want to.
When the implicit stuff is surprising, I'd rather it wasn't ever implicit.
- Treat it as a special arbitrary precision type, similar to Go
- Choose isize because it's the native size for the platform
- Make it a compile error when the type can't be inferred
The rationale for i32 in RFC 0212 is basically, "well C compilers usually do this", and some hand waving about cache (why not i16 or i8 then?!?). Then they chose f64 instead of f32 for floating literals, which undermines the cache argument. So really, Rust did it because C compilers do it, and C compilers do it to simplify porting old software, which doesn't apply to Rust.
Option 1 is not acceptable given Rust's attitude towards allocation.
We could do option 2, it's true.
> The rationale for i32 in RFC 0212 is basically, "well C compilers usually do this"
I don't agree with this; but it doesn't really matter at the end of the day, it's been years and this can't really change.
Regardless, I appreciate the elaboration :) It helps me understand the way others think about Rust.
#[derive(Debug)]
struct Foo<T> { pub bar: T }
fn hmm<T>(x: T) -> Foo<T> {
Foo { bar: x }
}
fn main() {
let f:Foo<f32> = hmm(1.23);
print!("got: {:?}\n", f);
}