It's unbelievably ugly. Every piece of code working with any kind of integer screams "I am hardware dependent in some way".
E.g. in a structure representing an automobile, the number of wheels has to be some i8 or i16, which looks ridiculous.
Why would you take a language in which you can write functional pipelines over collections of objects, and make it look like assembler.
If you do care, then isn't it better to specify it explicitly than trying to guess it and having different compilers disagreeing on the size?
We should all agree on int and uint; not some isize nonsense, and not bobint or suzyint.
You know, that describes pretty much everyone who has anything to do with Rust.
"My ls utility isn't written in Rust, yikes! Let's fix that!"
"The comments under this C++-related HN submission aren't talking about Rust enough, yikes! Let's fix that!"
I'm obviously pointing to a solution: have a standard module that any Rust program can depend on coming from the language, which has a few sanely named types. Rather than every program defining its own.
`isize`/`usize` should only be used for memory-related quantities — that's why they renamed from `int`/`uint`.
Usually, I just want the widest type that is efficient on the machine, and I don't want it to have an inappropriate name. I don't care about the wasted space, because it only matters in large arrays, and often not even then.
In Rust, that's not really the case. `i32` is the go-to integer type.
`isize` on the other hand would look really weird in code — it's an almost unused integer type. I also prefer having integers that don't depend on the machine I'm running them on.
It's going to get expensive on a machine that has only 64 bit integers, which must be accessed on 8 byte aligned boundaries.
Therefore, declaring that int32 is the go to integer type is myopic.
Forty years ago, a program like this could be run on a 16 bit machine (e.g. MS-DOS box):
#include <stdio.h>
int main(int argc, char **argv)
{
while (argc-- > 0)
puts(*argv++);
return 0;
}
Today, that same program does the same thing on a modern machine with a wider int.
Good thing that some int16 had not been declared the go to integer type.
Rust's integer types are deliberately designed (by people who know better) in order to be appealing to people who know shit all about portability and whose brains cannot handle reasoning about types with a bit of uncertainty.
The are a few historical architectures that couldn't handle smaller integers, like the first generation Alpha, but:
a) those are long dead.
b) hardware engineers learnt from their mistake and no modern general purpose architecture has repeated it (specialized architectures like DSP and GPU are another story though).
c) worst case scenario, you can simulate it in software.Can you remember the name for a 128 bit integer in your preferred language off the top of your head? I can intuit it in Rust or Zig (and many others).
In D it's... oh... it's int128.
A type that provides a 128 bit integer exactly should have 128 in its name.
That is not the argument at all.
The problem is only having types like that, and stipulating nonsense like that the primary "go to" integer type is int32.
On the C++ side, I sometimes use an alias that contains the word "short" for 32-bit integers. When I use them, I'm explicitly assuming that the numbers are small enough to fit in a smaller than usual integer type, and that it's critical enough to performance that the assumption is worth making.