70

In the Kotlin language we, by default, have to initialize each variable when it is introduced. To avoid this, the lateinit keyword can be used. Referring to a lateinit variable before it has been initialized results in a runtime exception.

lateinit can not, however, be used with the primitive types. Why is it so?

Kallja
  • 5,362
  • 3
  • 23
  • 33

3 Answers3

65

For (non-nullable) object types, Kotlin uses the null value to mark that a lateinit property has not been initialized and to throw the appropriate exception when the property is accessed.

For primitive types, there is no such value, so there is no way to mark a property as non-initialized and to provide the diagnostics that lateinit needs to provide. (We could try to use a separate marker of some kind, but that marker would not be updated when initializing the field through reflection, which is a major use case of lateinit).

Therefore, lateinit is supported for properties of object types only.

sschuberth
  • 28,386
  • 6
  • 101
  • 146
yole
  • 92,896
  • 20
  • 260
  • 197
  • 53
    Could you clarify in the answer, why `lateinit Int` couldn't be represented with the `Integer` type in runtime, which is able to hold `null` value while it hasn't been initialized? – Ilya Aug 04 '16 at 18:13
  • 1
    @Ilya because an `Integer` is not an `int`. It is a boxed type, and it matters when setting stuff natively or through reflection. – Gustavo Maciel Oct 22 '17 at 10:19
  • 4
    So, I think Kotlin wraps up the primitive types to object(for example int to Int). However, why can't Int hold null as it is an object ? Also, why can't we declare a parameter as nullable and lateinit it ? (var x: Int?) – Yao Oct 30 '17 at 18:12
  • 2
    @Yao for the same reason explained by yole. Basically, you need an unused value that can be used to flag the fact that the var is not inited. As explained, there is no such value for primitives (all values that can be hold by a primitive var are valid). The same problem holds for nullable vars: all values, included null, are valid (you can init a nullable var with null). So no unused value remains to mark the var as not inited. – Ekeko Feb 04 '18 at 13:29
  • 3
    @GustavoMaciel but if I say `lateinit var int: Int?` then I don't see why that wouldn't work, since Kotlin is already representing `Int?` with `Integer` ... – forresthopkinsa May 12 '18 at 19:13
  • 4
    @forresthopkinsa Because `lateinit` and `?` are conflicting. The former says you have a variable that will always have some value after being initialized, the latter says you have a variable that may or may not have some value. You shouldn't need to `?.` or ever check for nullity on a `lateinit` var. – Gustavo Maciel May 14 '18 at 00:27
  • @GustavoMaciel that makes sense – forresthopkinsa May 14 '18 at 16:32
  • @GustavoMaciel sometimes, you need to distinguish the variable initialized as a null and uninitialized variable. – Xwtek Sep 30 '19 at 14:04
  • The difference between `Int` and `Int?` is, that the first can have all numbers as value, the second can have all numbers and `null` as value. So why can't we have a `lateinit Int` that has `null` as marker value for not yet initialized? :-/ – Vampire Aug 14 '20 at 22:29
  • So what is the recommendation for primitives, just keep them as `var` and initialize them to zero (even though it isn't a valid value)? – codingjeremy Oct 26 '20 at 23:57
  • 1
    I was under the impression, that all this java-like primitives vs. objects thing is now gone... But now I cannot use lateinit on Double... – spyro Jun 22 '21 at 14:33
  • I think that all that makes sense in a technical way (like so many restrictions and quirks do in Java). But nevertheless, it' just confusing from a developers standpoint. What ever the best workaround for this might be, it should IHMO be handled by the compiler. – spyro Sep 23 '22 at 07:52
9

A short answer is that with primitives you can always use 0 as the default, and with nullable types null as a default. Only non-nullable non-primitive types may need lateinit to work around the type safety system.

Actually, there is no need for initializing a variable in Kotlin as long as it has a value before the first access and it can be statically proved. Which means this code is perfectly valid:

fun main(args: Array<String>) {
    var x: Int
    val y: Double

    x = 0
    y = x + 0.1

    println("$x, $y") 
}

But there are (rare) cases when the initialisation cannot be statically proved. The most common case is a class field which uses any form of dependency injection:

class Window {
    @Inject lateinit parent: Parent
}
voddan
  • 31,956
  • 8
  • 77
  • 87
  • 1
    I think this is slightly misleading. It suggests the *only* reason for needing lateinit is to give a hint to the compiler when it's not smart enough to figure out if a property is initialized. Another totally valid use case (which would be especially useful for primitives) is to ensure that a descriptive exception is eagerly thrown if client code tries to access a value before it has been initialized/calculated, rather than silently doing the wrong thing based on a default value of 0 or false. – Mike Rippon Feb 07 '20 at 18:18
  • @MikeRippon, while that is a possible reason to use it, it is not the intended use by the designers of Kotlin. For that use, they provide `Delegates.notNull()`. They kept `lateinit` kind of low-level, high performance, and Java-reflection-friendly. Having these two different features is necessary so we can have working non-nullability with classes that are injected via Java libraries. – Tenfour04 Jul 11 '23 at 15:51
-3

I think that in case of primitives it's less resources taking to simply initialise it to let me say 0 and hold the simple value in memory rather than store extra information about the object nullability which is used by lateinit mechanism.

Correct me if it's not the case.

Artur Ex
  • 43
  • 7