There is no point in measuring array sizes in size_t. I don't make bigger allocations >2G. (At some point this assumption will probably break and I will have to re-think my approach. Shouldn't we all move to 64-bit integers by default already?)
I think almost every Rust program I've ever published regularly encounters files greater than 2GB (even 4GB), and if I had used C and its `int` type everywhere, I'd be in for a very very bad time.
This of course doesn't mean I am allocating >2G on the heap, but I might memory map the file. Or there might be some other counter (line counter? byte counter?) where using `int` would just fail.
There are even some alternatives to my tools written in C, and either they or their dependencies use `int` instead of `size_t`, and that leads to actual bugs their end users hit in exactly the cases where files are greater than 2GB.
Getting integer sizes right is important, and it's not just in cases where you're putting >2G on the heap.
I prioritize on getting their values right :-). So far I have not encountered bugs due to my pretty uniform usage of int. But if they had to deal with allocations >2G, my programs would just die.
Yup, I make some exceptions as well, for example to measure time in microseconds, or to measure the size of very large streams. And of course I try to assert that all downcasts to int are valid, and that my integer operations don't overflow, etc. (why do CPUs still not support overflow exceptions?)
I'm pretty sure we could get rid of quite some historical baggage in terms of integer types. For example, I'm currently working on a network module, and there is a type socklen_t which is to indicate the size of a socket structure. I might be missing something, but to me there is no good reason not to use simply int.