What numeric types does Kotlin provide for whole and fractional numbers, and how do you write integer literals in hex, binary, with separators, and as a Long?
answer
- Byte/Short/Int/Long + Float/Double
- 0x hex, 0b binary, no octal
- underscores = readability only
- L = Long, f/F = Float
- literal defaults: Int / Double
basics
~10 sWhole numbers: Byte, Short, Int, Long. Fractional: Float, Double. Write hex as 0xFF, binary as 0b1010, use underscores like 1_000 for readability, and add an L suffix (1L) to make a Long.
solid answer
~40 sKotlin's built-in number types are Byte (8-bit), Short (16-bit), Int (32-bit), Long (64-bit) for integers, and Float (32-bit) and Double (64-bit) for IEEE-754 floating point. Integer literals support hexadecimal (0xFF), binary (0b1010), and underscores as visual separators (1_000_000). There is no octal literal. A trailing L makes a Long (1L); without it the literal defaults to Int (or auto-fits a target type). Floating-point literals default to Double; an f or F suffix makes a Float (1.0f). You can mix forms, e.g. 0xFF_FFL is a hex Long. All of these are real classes (Int, Long, etc.), not language-level primitives, though the compiler maps them to JVM primitives where possible.
code
kotlin · 6 linesval mask = 0xFF // Int 255
val flags = 0b1010 // Int 10
val population = 8_000_000_000L // Long
val pi = 3.14 // Double
val ratio = 0.5f // Float
println(mask + flags) // 265go deeper
Names the six types and writes 0xFF, 0b1010, 1_000, 1L, 1.0f correctly.
Explains default inference (Int vs Long, Double for decimals) and that there is no octal.
Notes these are classes not primitives and that auto-widening of an over-large literal picks Long.
Connects literal/type choices to readability and JVM codegen, and reasons about when to force suffixes in APIs.
## The numeric types Kotlin has six built-in numeric types, each a real class in `kotlin` package: - **Integers:** `Byte` (8-bit), `Short` (16-bit), `Int` (32-bit), `Long` (64-bit). - **Floating point:** `Float` (32-bit IEEE-754), `Double` (64-bit IEEE-754). Unlike Java there are no `int`/`long` *language* primitives you write in source — you always use the class names. (The compiler still emits JVM primitives under the hood; see boxing.) ## Integer literal forms ```kotlin val dec = 1000 // decimal val hex = 0xFF // hexadecimal -> 255 val bin = 0b1010 // binary -> 10 val grouped = 1_000_000 // underscores are ignored, just readability val big = 1_234L // Long via L suffix ``` - **Hex** uses the `0x`/`0X` prefix; digits `0-9 a-f`. - **Binary** uses the `0b`/`0B` prefix. - **There is no octal literal** in Kotlin (no leading-zero octal like C/Java). - **Underscores** (`_`) may appear between digits as visual separators and are stripped by the compiler; they cannot lead, trail, or sit next to the prefix. - **`L` suffix** (uppercase only — lowercase `l` is disallowed to avoid confusion with `1`) makes the literal a `Long`. ## Floating-point literal forms ```kotlin val d = 1.0 // Double by default val f = 1.0f // Float via f/F suffix val sci = 1.5e3 // scientific notation -> 1500.0 (Double) ``` A literal with a decimal point or exponent defaults to **`Double`**. Add `f`/`F` for `Float`. ## Default type inference An unsuffixed integer literal is inferred as `Int` if it fits in 32 bits; if it exceeds `Int.MAX_VALUE` it is inferred as `Long` automatically. You can still force `Long` with `L` for clarity even when it fits. ```kotlin val a = 100 // Int val b = 10_000_000_000 // Long (too big for Int) val c = 100L // Long, forced ``` These literal rules apply identically across hex/binary/decimal forms.
- Why is lowercase 'l' not allowed as a Long suffix?Because lowercase 'l' is visually confusable with the digit '1'; Kotlin only accepts uppercase 'L'.
- Does Kotlin support octal literals?No. Only decimal, hexadecimal (0x) and binary (0b) integer literals exist; there is no leading-zero octal form.
Suffixes are like unit labels on a number: 'L' says litres (Long), 'f' says feet (Float) — same digits, different declared size.
saying these in an interview costs you the question
- Claiming Kotlin has C-style primitives (int/long) you write in code
- Saying a leading zero like 0777 is octal in Kotlin
- Thinking underscores change the value or only work in certain positions arbitrarily
- Believing an unsuffixed 1.0 is a Float
- Using lowercase l for Long