skip to content

What are Kotlin's unsigned integer types, and how do you write unsigned literals?

level: juniorimportance: should knowfreq 35%

answer

  1. UByte/UShort/UInt/ULong = 8/16/32/64 bits, no sign bit
  2. u suffix = UInt by default; uL = ULong
  3. 0xFFu, 0b1010u, 1_000_000u all valid
  4. UByte/UShort have no own suffix — use expected type
  5. No negative unsigned literals

basics

~20 s

Kotlin has four unsigned integer types: UByte, UShort, UInt, and ULong. They only hold zero and positive numbers. You write unsigned literals by adding the suffix u (or uL for ULong), like 42u or 0xFFu.

solid answer

~40 s

Kotlin provides UByte (8-bit), UShort (16-bit), UInt (32-bit), and ULong (64-bit). They represent only non-negative values, so their max range is larger than the signed counterpart (UInt max is 4_294_967_295 vs Int 2_147_483_647). You create unsigned literals with the u suffix: 42u, 0xFFu, 0b1010u. The compiler infers UInt by default, widening to ULong only when the value exceeds UInt's range. To force ULong use uL: 42uL. There is no signed equivalent that allows negative literals here — writing -1u is not a valid unsigned literal of -1; unary minus is not defined the way you might expect. Use them for bit manipulation, hashing, and interop where the full positive range matters.

code

kotlin · 5 lines
kotlin
val port: UShort = 8080u
val mask: UInt = 0xFF00u
val big = 4_294_967_295u   // UInt.MAX_VALUE
val huge = 10_000_000_000uL // ULong
println(UInt.MAX_VALUE)     // 4294967295

go deeper

for a junior

Names the four types and the u/uL suffixes, and knows they hold only non-negative values.

for a middle

Explains default inference to UInt vs ULong and how UByte/UShort come from an expected type.

for a senior

Discusses the missing unary-minus, all-ones bit patterns, and when unsigned actually pays off over Int.

for a principal

Frames unsigned-type usage as an interop/protocol/bit-twiddling concern and weighs readability/interop costs against the idiomatic Int default.

## The four unsigned types Kotlin defines four unsigned integer types, each mirroring a signed type's bit-width but using all bits for magnitude (no sign bit): - **UByte** — 8 bits, range `0 .. 255` (`UByte.MIN_VALUE`/`UByte.MAX_VALUE`) - **UShort** — 16 bits, range `0 .. 65_535` - **UInt** — 32 bits, range `0 .. 4_294_967_295` - **ULong** — 64 bits, range `0 .. 18_446_744_073_709_551_615` Because there is no sign bit, the maximum positive value is roughly double that of the matching signed type. ## Writing unsigned literals You mark an integer literal as unsigned with the **`u`** (or `U`) suffix: ```kotlin val a = 42u // UInt (default unsigned type) val b = 0xFFu // UInt, hex literal = 255 val c = 0b1010u // UInt, binary literal = 10 val d = 42uL // ULong (u + L) val e: UByte = 255u // type-inferred narrowing via expected type ``` Rules to remember: - The default inferred type for a `u`-suffixed literal is **`UInt`**, unless the value is too large for UInt, in which case it becomes **`ULong`**. - Use **`uL`** (or `UL`) to force `ULong`. - There is **no literal suffix for UByte or UShort**; you get those via an expected/target type, e.g. `val x: UByte = 200u`. - Underscores for readability still work: `1_000_000u`. ## No negative unsigned literals Unsigned types cannot represent negative numbers. `-1u` does not give you "all bits set"; instead the unary minus operator is **not defined** for unsigned types, so it won't compile the way you'd write a negative. To get the all-ones bit pattern use `UInt.MAX_VALUE` or `(-1).toUInt()` via explicit conversion. ## When to use them Unsigned types shine for **bit manipulation**, **hashing**, representing **byte/word values from binary protocols**, and **interop** where a value is conceptually non-negative and may exceed the signed max. For everyday counting, signed `Int` remains the idiomatic default.

  • What type does the literal 42u have, and why?
    UInt. The u suffix produces UInt by default; it only widens to ULong if the value exceeds UInt's range or you add the L suffix.
  • How would you get a UByte of value 200?
    Provide an expected type: val b: UByte = 200u. There's no dedicated UByte suffix, so the compiler narrows the UInt literal to the declared type.

Like a car odometer that only counts up: it uses every digit for distance, so it reaches a higher number than a gauge that reserves a slot for direction.

saying these in an interview costs you the question

  • Claiming -1u gives an all-ones unsigned value (unary minus isn't defined that way)
  • Saying there's a 'uB' or 'uS' suffix for UByte/UShort
  • Thinking UInt and Int have the same maximum value
  • Believing the default unsigned literal type is ULong

context

resolving links…