Question: Why are the sizes or lengths of the string and Builder procedures data type all received and returned as Int's?

[joaocarvalhoopen]

Hello,

Question: Why are the sizes or lengths of the string and Builder procedures data type all received and returned as Int's?

They can never be a negative value, right?
I really think that it should be the max addressable size of a unsigned register for the platform memory, (ex: 4 GB for a 32 bit's architecture and not 2 GB), that mean something like a usize in Rust.
Right?
This allows to easily find many bugs in Rust and to use the types to help you. And doesn't limit the max size that can be used by halving it.

Example:

builder_len :: proc(b: Builder) -> (res: int) {…}

Thank you,

Best regards,
João Carvalho

[joaocarvalhoopen]

Hello,

len() returns a Int, this is a major flaw in the design of Odin! As in a 32bit's now and in a 64 bit's in same (many) years, you are not able to create an array of bytes with the max size of your memory. The example that is easy to think about is for a 32 bits CPU architecture, the fact that you can only create a array or buffer of 2GB Max when with a size_t in C ou C++ you could allocate one with 4 GB.

From the documentation:

len

len :: proc(v: Array_Type) -> int {…}

The len built-in procedure returns the length of v according to its type:

Array: the number of elements in v.
Pointer to (any) array: the number of elements in v^ (even if v is nil).
Slice, dynamic array, or map: the number of elements in v; if v is nil, len(v) is zero.
String: the number of bytes in v
Enumerated array: the number elements in v.Enum type: the number of enumeration fields. #soa array: the number of elements inv; if visnil, len(v)is zero. #simd vector: the number of elements inv`.

For some arguments, such as a string literal or a simple array expression, the result can be constant.

Best regards,
João Carvalho

[Beefster09]

From what I understand, int is always the same size as a pointer in Odin, i.e. 64 bits on 64 bit architectures.

[Kartoffelsaft]

Like with what Beefster09 said, int in Odin is much more akin to isize in Rust than an int in C. Sure, you might half the amount of memory you can access, but on a 64-bit system that will only matter if you have a string/array between 8 and 16 exabytes, which in my opinion is worth losing if it means that, for example, the bounds checker says -1 is out of range rather than 18 quintillion (which is how it'd be printed if you did something like arr[len(arr)-1]). I get that an unsigned int would be more "correct", however I think the tradeoff is worth it.

[joaocarvalhoopen]

Hello,
thank you for your both fast replies,
I yesterday was thinking about this specific matter and it become clear to me that there was other motive to want it to be an int, is the quality of life of the programmer, because if the majority of the type used in a program is the int then unlike in Rust you don't have to be constantly casting to and from a usize to a int or equivalent to that in Odin each time you have to compare with a int variable or inside an index of a array, vector, slice. So it's a trade off but is a nice tradeoff.
And then again you only would have that real problem if you needed a single array of bytes off the size of the all memory, and would not have that problem if you had an array of i16 bytes, so you could always use in that uncommon specific case two arrays off bytes instead and work with the two in conjunction. Because it doesn't limit your use of memory it only limits the max size of an array, vector, or slice.

Once again thank you for the response,

Best regards,
João Carvalho