If we could redesign kotlin, what names for numeri...

# stdlib

[mcpiroman]

If we could redesign kotlin, what names for numeric primitives would you prefer?
1️⃣ Java-like (current): Int, UInt, Long, Short, Float, Double
2️⃣ Rust-like: I32, U32, I64, I16, F32, F64
3️⃣ Mixed: Int32, UInt32, Int64, Int16, Float32, Float64
🧵 Other?

[mbonnin]

Anything as long as we can bitshift with `<<`😄

[mbonnin]

Small preference for explicit 32 and 64 so 2️⃣ or 3️⃣

[jw]

Yeah Long, Short, and Double are such terrible names. I voted for 2 and 3 because anything is better than 1, but I lean slightly toward the more verbose 3 for some reason. In Rust somehow the lowercase letters are better whereas the uppercase ones look weird to me (but i'd still take them over 1!)

[Klitos Kyriacou]

There's a 4th option: like in Pascal, where you can declare a variable as 0..65535, for instance, and the compiler decides how many bits to use.

[Sam]

Does that also work for floating point? Doesn’t seem so obvious how that would work, but maybe it could be done

[Klitos Kyriacou]

No, only for discrete quantities as far as I'm aware.

[kevin.cianfarini]

I would prefer the lowercase ones like i32 and u8 if we could ensure they wouldn’t be boxed into an object type. Since Kotlin blurs those lines I think I32 and what not would make more sense.

That’s my atrophied Java knowledge speaking though.

[christophsturm]

I think i32 and i64 is suitable for low level code, like a kernel or drivers, but for a high level language i prefer int and long.

[jw]

but why? "long" and "short" don't tell you anything. how is a "long" related to an "int" but a "double" related to a "float"?

[jw]

why isn't a "double" 2x an "int" and a "long" 2x a "float"?

[Sam]

char can get in the sea

[christophsturm]

i guess int, long and float would be better, where float would be a floating point number with double precision.

[jw]

If i were rewriting the "friendly" names I would probably do HalfInt, Int, DoubleInt and HalfFloat, Float, and DoubleFloat.

[jw]

I think using english modifiers breaks down. What do you call the values for wider types such as 128, 256, and 512-bit values? I suppose you could do QuadrupleInt, `OctupleInt`(?), and whatever 16 is... but these aren't super friendly compared to Int128, Int256, and Int512 which retain their shortness, ability to auto-complete based on the type kind prefix, and aren't a huge leap to learn what the value means.

[ilya.gorbunov]

Is Int256 a 256-bit int or an int that can hold 256 values, i.e. a byte? 🦖

[kevin.cianfarini]

I mean we wouldn’t have an Int9223372036854775807 to represent a signed 64bit number so I feel like it would make more sense to denote bitwidth.

[kevin.cianfarini]

And yeah I know that’s not all the possible values of a 64 bit int but I was too lazy to figure it out lol.

[Klitos Kyriacou]

How about using the syntax of COBOL's declare myIntVariable pic '999999999' ?
I'll get my coat...

[christophsturm]

i think its a bit unintuitive that an int is just 32 bit. the default integer type should be really bigger nowadays.

[jw]

Don't tell JavaScript that. It can only represent whole numbers up to 2^53. Types requiring larger bit widths must be emulated manually or using bignum which incur significant performance impact.

[ephemient]

IMO Int is fine for "this is the most common integral type". the other Java-like names… eh, less great but we're used to them already

[ephemient]

for Kotlin/Native it would be nice to have a standard set of CInt etc. types or aliases for interop with C (can't use <http://kotlin.Int|kotlin.Int> since C's int is different sizes on different platforms)

[ephemient]

but that's just a complete distraction on Kotlin/JVM where bitness doesn't matter

[Luke]

Don't `typealias`es make it possible to have all those cases? Maybe the standard library could define the most common ones?

[ephemient]

it is, but we currently need @UnsafeNumber to show that "this typealias may be different on different targets so even though it's equivalent to Int on your current target, this code that assumes they're the same will fail to compile on a target where it aliases `Long`" and it's a ugly pain

[ilya.gorbunov]

There's a plan to provide some type that would mean an Integer with different bit widths on different Kotlin/Native platforms in order to be able to commonize these platform's API: https://youtrack.jetbrains.com/issue/KT-41509/Commonizer-Commonize-numeric-types-with-different-bit-width