# Why doesn't Kotlin use better names for number types? **URL:** \ **Category:** Uncategorized\ **Created:** [March 11, 2021, 4:24pm UTC](https://discuss.kotlinlang.org/t/why-doesnt-kotlin-use-better-names-for-number-types/21175 "2021-03-11T16:24:40Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![medium](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/medium/32/10404_2.png) [@medium](https://discuss.kotlinlang.org/u/medium)\ **Post date:** [March 11, 2021, 4:24pm UTC](https://discuss.kotlinlang.org/t/why-doesnt-kotlin-use-better-names-for-number-types/21175/1 "2021-03-11T16:24:40Z")
Kotlin uses [number types](https://kotlinlang.org/docs/basic-types.html#numbers) with not self-explanatory names like `Short`, `Int`, `Long`, `Float`, `Double`. Today I stumbled over a [discussion](https://news.ycombinator.com/item?id=26421690) in which the questions “`Double` what?” and “`Long` what?” came up. Kotlin decided to use other names than Java for number types, so the argument to use the same names as Java wouldn’t apply. But why are not more descriptive names used then? In my opinion [Rust](https://doc.rust-lang.org/rust-by-example/primitives.html) has better names: - signed integers: `i8` , `i16` , `i32` , `i64` , `i128` - unsigned integers: `u8` , `u16` , `u32` , `u64` , `u128` - floating point: `f32` , `f64` My suggestion for Kotlin would be: - `Byte` → `Int8` - `Short` → `Int16` - `Int` → `Int32` - `Long` → `Int64` - `Float` → `Float32` - `Double` → `Float64` Another advantage would be that other types like `Int128` could be added easily and consistently. Would it even be imaginable to deprecate such common names and to replace them with more descriptive ones in Kotlin? ---
**Author:** ![kyay10](https://avatars.discourse-cdn.com/v4/letter/k/c57346/32.png) [@kyay10](https://discuss.kotlinlang.org/u/kyay10)\ **Post date:** [March 11, 2021, 4:36pm UTC](https://discuss.kotlinlang.org/t/why-doesnt-kotlin-use-better-names-for-number-types/21175/2 "2021-03-11T16:36:05Z")
I see the merit in how this change can help beginners, but also I think that having the number of bytes after the type is just kind of too noisy if you get what I mean. It carries more of a mental weight to think about “well this is an int16 but this is an int32”, while with the current names the thinking is more like “okay well when I immediately see Int I know this is just normal code and when I see Double or Float then it’s something division or graphics related and oh when I see Short or Long this is either high-performance code or some rather specific usecase” and it sort of highlights that the default is to use Ints and Doubles almost everywhere, which programmers who are familiar with that are very used to nowadays. ---
**Author:** ![Varia](https://avatars.discourse-cdn.com/v4/letter/v/b9e5f3/32.png) [@Varia](https://discuss.kotlinlang.org/u/Varia)\ **Post date:** [March 11, 2021, 5:05pm UTC](https://discuss.kotlinlang.org/t/why-doesnt-kotlin-use-better-names-for-number-types/21175/3 "2021-03-11T17:05:44Z")
Pretty sure that the main reason is that they are named that way in Java. Since interoperability with Java is a very high priority in Kotlins design, it would be confusing if the same types had vastly different names between the two languages. As for why they are named that way in Java, my guess is that it follows the tradition from C. In C, `long` and `short` are just shorthand aliases for `long int` and `short int` respectively. Just be glad that at least the ranges of the integer types are well-defined in Java and Kotlin, unlike in C. ---
**Author:** ![mtimmerm](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/mtimmerm/32/7160_2.png) [@mtimmerm](https://discuss.kotlinlang.org/u/mtimmerm)\ **Post date:** [March 13, 2021, 1:32pm UTC](https://discuss.kotlinlang.org/t/why-doesnt-kotlin-use-better-names-for-number-types/21175/4 "2021-03-13T13:32:27Z")
What Kotlin really needs is a 53-bit integer type, and nobody would want to call it a `Medium` or `Longish`, so I think this scheme has merit 🙂 ---
**Author:** ![darksnake](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/darksnake/32/2479_2.png) [@darksnake](https://discuss.kotlinlang.org/u/darksnake)\ **Post date:** [March 13, 2021, 1:59pm UTC](https://discuss.kotlinlang.org/t/why-doesnt-kotlin-use-better-names-for-number-types/21175/5 "2021-03-13T13:59:22Z")
```kotlin typealias Float32 = Float ``` Solves all your problems without inventing new ones. ---
**Author:** ![trejkaz](https://avatars.discourse-cdn.com/v4/letter/t/8797f3/32.png) [@trejkaz](https://discuss.kotlinlang.org/u/trejkaz)\ **Post date:** [March 15, 2021, 1:35am UTC](https://discuss.kotlinlang.org/t/why-doesnt-kotlin-use-better-names-for-number-types/21175/6 "2021-03-15T01:35:12Z")
Don’t worry, non-believers of this one will feel the pain when Kotlin is forced to introduce the LongLong type in the future. (Those of us who work in file formats where some data is not stored in convenient 8-bit blocks already feel this sort of pain because we wish we could have structs with things like Int1 or Int4 in them.) ---
**Author:** ![arocnies](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/arocnies/32/5143_2.png) [@arocnies](https://discuss.kotlinlang.org/u/arocnies)\ **Post date:** [March 15, 2021, 2:54am UTC](https://discuss.kotlinlang.org/t/why-doesnt-kotlin-use-better-names-for-number-types/21175/7 "2021-03-15T02:54:54Z")
I doubt Java or Kotlin would be forced to add something like longlong. I prefer the current names as I think application programming it’s relatively practical, easy to learn (including what they mean), and they’re sane defaults. I understand if someone disagrees though. > [@trejkaz](#): > > Those of us who work in file formats where some data is not stored in convenient 8-bit blocks already feel this sort of pain because we wish we could have structs with things like Int1 or Int4 in them. Value classes (aka your own custom primatives) should fix this, no? If you want some crazy `Int42` or `Float7`, you can make it yourself and get all the nice optimizations associated with value classes. ---
**Author:** ![darksnake](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/darksnake/32/2479_2.png) [@darksnake](https://discuss.kotlinlang.org/u/darksnake)\ **Post date:** [March 15, 2021, 12:57pm UTC](https://discuss.kotlinlang.org/t/why-doesnt-kotlin-use-better-names-for-number-types/21175/8 "2021-03-15T12:57:07Z")
I work with file formats. If I need new types, I create them inside my program. It is that simple. ---
**Author:** ![clovisai](https://avatars.discourse-cdn.com/v4/letter/c/a9adbd/32.png) [@clovisai](https://discuss.kotlinlang.org/u/clovisai)\ **Post date:** [March 15, 2021, 3:16pm UTC](https://discuss.kotlinlang.org/t/why-doesnt-kotlin-use-better-names-for-number-types/21175/9 "2021-03-15T15:16:08Z")
Kotlin did rename `Object` → `Any` and `void` → `Unit`; `Float` → `Float32` doesn’t sound far-fetched. However, I agree with Varia: names should be simple, and after you read the documentation of `Float` once, you’ll never have any questions about it. Also, Kotlin is not an ultra-performance language, trying to use `Short` instead of `Int` will not, in most cases, speed up your program, so it’s better if beginners don’t think too much about it. ---
**Author:** ![bjonnh](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/bjonnh/32/8106_2.png) [@bjonnh](https://discuss.kotlinlang.org/u/bjonnh)\ **Post date:** [March 16, 2021, 1:28pm UTC](https://discuss.kotlinlang.org/t/why-doesnt-kotlin-use-better-names-for-number-types/21175/10 "2021-03-16T13:28:57Z")
Shorts are not always faster than Ints in C either. It depends greatly on the operations you are doing, how much cache is involved etc etc. ---
**Author:** ![medium](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/medium/32/10404_2.png) [@medium](https://discuss.kotlinlang.org/u/medium)\ **Post date:** [March 19, 2021, 3:25pm UTC](https://discuss.kotlinlang.org/t/why-doesnt-kotlin-use-better-names-for-number-types/21175/11 "2021-03-19T15:25:05Z")
It is not an actual problem _I_ have with these names, since I learned these types some 20 years ago. It was more a fundamental thought if the language could be improved here. So, as much as I like your idea with type aliases, it wouldn’t make it into any tutorial for beginners, because it would be even more confusing, if it wouldn’t be the standard name. However, since most Kotlin folks would have some Java background, new names like `Int64` might be confusing anyway. ---
**Author:** ![dalewking](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/dalewking/32/1496_2.png) [@dalewking](https://discuss.kotlinlang.org/u/dalewking)\ **Post date:** [April 10, 2021, 5:50pm UTC](https://discuss.kotlinlang.org/t/why-doesnt-kotlin-use-better-names-for-number-types/21175/12 "2021-04-10T17:50:44Z")
On the floating point side the distinction comes from the IEEE 754 spec that defines the floating point representations of numbers. It defines single-precision floating point (which it calls binary32) and double-precision floating point (which it calls binary64). It also defines half-precision, quadruple-precision, and even octuple-precision. So the answer to Double what?, the answer is double the precision. While it may have been more consistent to name these as `Single` and `Double` as was done in Delphi and Visual Basic, there is a long history of calling of these `float` and `double` that dates back at least 50 years to the C language. Adding the number of bits for these is not really relevant as the primary concern is how precise the number is, not necessarily how man bits it takes up. The number of bits was more of a concern in early days of computing. On the integral side Kotlin is following the 25-year old example of Java, which was a vast improvement on the old days of C/C++. In C and C++ how many bits an int or long int took up was platform specific. Int could be 16-bits, 32-bits, or 64 bits and long int could be 32-bits or 64-bits. It was not defined by the language, which lead to the need to define aliases like int32 to remove the ambigutity. Java at least standardized on 2 primary integral types, long and int and fixed their size as 64 and 32 bits. I say they are the primary types because all math is done in either 32 or 64 bits. There are the short, char, and byte types (along with unsigned versions in Kotlin) that define smaller types but they are always promoted to 32 or 64 bits for any math. So the answer to Long what? is a Long Int. In C you could use long as an adjective like signed and unsigned and say `long int` but could shorten it to just `long` and that became the norm which Java and Kotlin both continued. Since Kotlin was originally a better Java it made since to follow the same naming. If you don’t like those names you are free to use typealias to make your own names. ---
**Author:** ![raphael.tarita](https://avatars.discourse-cdn.com/v4/letter/r/3ab097/32.png) [@raphael.tarita](https://discuss.kotlinlang.org/u/raphael.tarita)\ **Post date:** [April 10, 2021, 10:09pm UTC](https://discuss.kotlinlang.org/t/why-doesnt-kotlin-use-better-names-for-number-types/21175/13 "2021-04-10T22:09:11Z")
> [@medium](#): > > Kotlin decided to use other names than Java for number types, […] Actually, no. And that’s also the answer of why the names are like they are: they are copied over from Java for (mental) interoperability. I don’t know how you came to the conclusion that they changed the names, because ```auto Java -> Kotlin boolean -> Boolean byte -> Byte char -> Char short -> Short int -> Int long -> Long float -> Float double -> Double ``` The only difference is that the names start with uppercase letters, which is a convention for non-primitives. Since Kotlin has no primitives (at use-site), this makes perfect sense. You might have been confused by Javas boxed (non-primitive) numbers, like `Integer`. They are _not_ the same as Kotlin pseudo-primitives, since those might represent an unboxed primitive at runtime based on the usage (non-nullable, not as generic, …). > [@clovisai](#): > > Kotlin did rename `Object` → `Any` and `void` → `Unit` ; […] - Yes, `Object` became `Any`, although those two types are not considered the same in Kotlin/JVM. - `void` and `Unit` are fundamentally different. `Unit` in Kotlin was necessary to increase the languages’ expressiveness. It’s not a renaming, it’s a different thing. Naming that different thing `Void` as well would just lead to confusion. ---
**Author:** ![clovisai](https://avatars.discourse-cdn.com/v4/letter/c/a9adbd/32.png) [@clovisai](https://discuss.kotlinlang.org/u/clovisai)\ **Post date:** [June 1, 2021, 8:14pm UTC](https://discuss.kotlinlang.org/t/why-doesnt-kotlin-use-better-names-for-number-types/21175/14 "2021-06-01T20:14:56Z")
Also, `void` is just wrong. The term `void` refers to the empty set, and it is mathematically incorrect to say a function’s type is `void`, because that function therefore _cannot_ return. The real `void` type is named `Nothing` in Kotlin (I assume, because naming it `void` would confuse _everyone_, even if mathematically correct), and doesn’t exist in Java.