char / int / i8 / i32 and so on

[lerno]

I talked a bit about readability for int/floats in another thread. Reading through the sample code, I notice that "char" is actually there as i8. Can we perhaps take a page from java and introduce named types with fixed sizes?

bool = u1
byte = u8
char = i8
short = i16
ushort = u16
int = i32
uint = u32
long = i64
ulong = u64
float = f32
double = f64

I suggest that the bit-named types still remain (so char is alias to i8, it doesn't replace it). This allows us to postpone naming of f128 and allows easy insert of middle sized types like i24 if that ever would be interesting.

I'm not entirely sure that this is a good idea, but I think that either keep it the bits explicit for everything (including char) or use well defined aliases for all basic types.

[bas]

The short/long names do make the exact size ambiguous, especially since C2 is a close relative to C. So if you're programming in C2 and
using C libraries, an *int* in the c2-part of your code is different than an *int* in the c-part of the code. I don't think that's any good..

[lerno]

I was assuming C2 would use something like c_int, c_short, c_unsigned_short etc för C?

Also, since the bit widths would be same or equal to width of the corresponding values it should not run into issues.

So my argument is roughly:

• If one supports more than 8/16/32/64/128 widths, sure use i / u prefix. It's fine.
• If we only support 8/16/32/64/128 we're fine with a name that in C corresponds to a type with at least the given width

If we look at the types we have from c:

unsigned char = u8
signed char = i8
char = u8 OR i8 depending on architecture
short, short int = i16
int = min i16, i16 Win16, i32 on Win32, Win64, Unix, i64 on legacy Unix 64 bit
long, long int = i32 on Win16/32/64/ARM, i64 on Unix
long long = i64 on all platforms

Sorting away legacy systems we basically have:

char = u8 or i8
short = i16
int = i32
long = i32 or i64
long long = i64

The only place where we run into problems with assuming a bit width is "long" here. But since the proposal of long = i64 it's still at least the min size encountered *and* replaces long long for the most cases. "long" is a rather unnecessary type in C for most platforms today.

If char is kept then we have to decide on signed or unsigned anyway. Plus *java* has already standardized on these sizes with these names, as have C#.

If we want stuff like i24, i48 etc then sure, the bit size makes a lot of sense.

[bas]

In C2 there are already longer names for the C libs. So c_short, c_long, etc. These can be used if you want longer names..
Additionally I'm convinced that there should also be a pointer-size dependent variable. For this I'll add isize and usize.
Also many new languages (Rust, Zig) seem to be on this exact track as well.