Why Kotlin doesn't use `UInt` type for `String.len...

# getting-started

[Johann Pardanaud]

Why Kotlin doesn't use UInt type for String.length or Collection.size? Is this for JVM compatibility? Is it safe to assume those values will never be negative?

[mkrussel]

I don't know the actual reason, but I assume it would be that most people interact with it as an Int. It also predates UInt so changing it would be a pretty breaking change.

repeat(list.size - 1 {} would not compile anymore, one of the numbers would have to get casted. It's better than old languages where mixed type maths were allowed and you end up with the maximum UInt if size was 0.

I think it is safe to assume that it will not be negative. But a custom collection could do something very broken.

[Charles Flynn]

Presumably so it doesn't make doing basic arithmetic with those functions a pain.

[Johann Pardanaud]

But a custom collection could do something very broken.

I did not thought about that, you're right, it could bring some issues. 😬

[Charles Flynn]

I rarely use UInt even for non negative ints. If I really want to convey type information for my numbers I'm more likely to use a value type.

[Johann Pardanaud]

yep, I'm starting to think this could be better

[Alexey Belkov [JB]]

https://github.com/Kotlin/KEEP/blob/master/proposals/unsigned-types.md#non-negative-integers

While unsigned integers can only represent positive numbers and zero, it’s not a goal to use them where non-negative integers are required by application domain, for example, as a type of collection size or collection index value.

[Johann Pardanaud]

Really interesting, thank you Alexey!