3 ms·
Personally I would prefer i64, but the following are defensible: - Treat it as a special arbitrary precision type, similar to Go - Choose isize because it's t
by xscott 6y ago
Personally I would prefer i64, but the following are defensible:
- 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.
- steveklabnik 6y agoWe did option 3, and it made examples and docs very difficult. 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.
- xscott 6y agoYeah, I realize none of this can change. However, if there is ever a breaking version 2.0 on the roadmap, I'll tell you the features which keep me from actually using Rust. The i32 is pretty insignificant. :-)
- steveklabnik 6y agoThere is no plans at this time, but I'm always interested in hearing what folks have to say...