I think we have a very inconsistent state of integers.
On the one hand:
- We will apparantly get back integer fallback to
- The guide (as of 2014-09-07) uses
intas sole integer type.
This suggests we should have
int as a machine-fast integer type and not as pointer size.
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:
intis suggested to be renamed (to
size, or whatever, I don’t really care for this issue), it is brought up that people using
intas “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.
So I think all in all, we first need to clarify what our
int type is:
- 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.
- 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.