deleted

[acbaile]

deleted

[bas]

C2 started out with the short versions (u8, etc), then returned to versions. After a while, this didn't feel right, so it was changed back to the short
versions. In the end, it takes a bit of getting used to, but it is easier on the eyes. This is the same as Rust btw.

Encapsulation at compile time level does not exist anymore at all, since the C2 compiler has a different unit of compilation. Having no
headers avoids a lot of issues and increasing the unit of compilation also allows some pretty nice features.

[lerno]

I prefer the shorter 'u8' 'i8' 'f32' etc. However, I would actually like to see a plain "int" which is "native data size" for the platform just to keep things simple, readable and efficient.

[lerno]

I’ve written quite a bit of code with the i32/i64/f32 format - as well as using uint/int etc. Two issues:

• i32/i64 has poor readability in a loop syntax wise
• You sometimes want ”fastest int” - c2 has no concept of that right now. It’s important to be able to use different code in different architectures.
• For a loop i32/i64 is overspecification. You only want the most efficient thing to keep in a register and inc/dec

I *like* i32 etc, but we need to make fast loops easy. And we need to be able to determine register size in an easy way.

Introducing int = ”fastest that is at least 32 bit” would hit a sweet spot.

[lerno]

Hmm maybe. It sort of depends on how the macro system looks later on.

[bas]

Currently in C if you want to write portable code, you often avoid the use of int, since since changes
the behaviour between platforms. Other recent languages (like Rust) do still have a general integere type
(isize/usize in Rust). I'm not sure if there is a real performance penalty (and how big) of using a 32bit
integer on a 64bit system. If there is a big one, we should introduce a generic 'int' like type.

[lerno]

I would use it exclusively for loops BTW, for any data structure I'd use explicit sizes.

I did a little research and seems like the question is a bit deeper than I first thought. int/i32/i64 will affect register allocation, so performance depends a bit on the processor.

Something "good to have" out of the box is getting information form the compiler directly into the macro system to know things like data width, # and types of registers available, endianness and so on.

[bas]

It's common to store pointers in numbers. Code like that often keeps track of the meaning of the value. It could be a real number or a pointer.
For code like this, having a usize/isize is a real requirement.

[lerno]

I would have prefered using the well known Java convention of:

byte = i8
short = i16
int = i32
long = i64
float = f32
double = f64

Then extend to unsigned:

char = u8
ushort = u16
uint = u32
ulong = u64

However, if we want to support: i/u24 i/u48, f128 then that naming scheme is better. I prefer shorter if numbers are added. For the real horror example: NSUInteger of Objective-C on mac. That one is 32 bits or 64 depending on architecture. Aside from the obvious problem of 32/64 bit, the real pain is writing 4 uppercase followed by lower case. Hard to type as well as overly long.

[lerno]

I've recently discovered that i32 can be significantly faster than "register sized" int.