Integer types

[tbu]

I think we have a very inconsistent state of integers.

On the one hand:

• We will apparantly get back integer fallback to int.
• The guide (as of 2014-09-07) uses int as sole integer type.

This suggests we should have int as a machine-fast integer type and not as pointer size.

On amd64 we have int = i64, but i32 is a faster, still reasonable type. On the other x86, we have int = i32 which is fast and pointer sized. On the standard intel 16-bit CPUs, we would have to have int = i32 (if I interpret this correctly, because pointers need 20 bit), yet i16 would perform better.

On the other hand:

• When int is suggested to be renamed (to index, size, or whatever, I don’t really care for this issue), it is brought up that people using int as “I don’t care” is just a documentation issue.

In this case we’d keep int as pointer-sized, but have to educate users about this issue. This is currently virtually non-existant, as my other topic shows. Additionally the Guide would need to be updated, and integer fallback should fall back to i32 or similar.

Summary

So I think all in all, we first need to clarify what our int type is:

1. It’s a default integer type. Then use a integer type that is fast on machines. Guide, docs and integer fallback can stay the way they are.
2. It’s the pointer-sized integer type. It’s not necessarily fast. Guide and docs should be updated to use a fast integer type in “don’t care”-situations, so that we keep C-speed ( ). Integer fallback should probably fall back to a fast integer type or a fixed-size one.

[steveklabnik]

I only used int solely in the guide because all this was in flux, don’t take it as authoritative. I also over-annotate integer literals too.

[Gankra]

@tbu

On the standard intel 16-bit CPUs, we would have to have int = i32 (if I interpret this correctly, because pointers need 20 bit), yet i16 would perform better.

To my knowledge, Rust doesn't support 16-bit platforms, so this is irrelevant.

[tbu]

It doesn’t support those platforms yet. That doesn’t mean one should make possible support for it impossible or harder to achieve. (See e.g. how C compiles to almost anything.)

[kmcguire]

I think we could drop int and force the programmer to declare the type needed for correctness. We should have pointer for absolute memory addressing. Then offset for offsetting from a pointer.

This will force all old code to update for correctness.

If you wanted you could declare fastint and somehow declare a fallback integer if fastint can’t support the needed size. This will require work like a feature or something.