initialization - example - when in kotlin android

¿Por qué Kotlin no permite usar lateinit con tipos primitivos?

Question

En el lenguaje Kotlin, por defecto, tenemos que inicializar cada variable cuando se introduce. Para evitar esto, se puede usar la palabra clave lateinit . lateinit referencia a una variable lateinit antes de que se haya inicializado da como resultado una excepción de tiempo de ejecución.

lateinit no puede, sin embargo, usarse con los tipos primitivos. ¿Por que es esto entonces?

Answer 1

Creo que, en el caso de las primitivas, se requieren menos recursos para simplemente inicializarlo y dejarme decir 0 y mantener el valor simple en la memoria en lugar de almacenar información adicional sobre la nulabilidad del objeto que utiliza el mecanismo lateinit.

Corrígeme si no es el caso.

Answer 2

Para los tipos de objeto, Kotlin usa el valor null para marcar que una propiedad lateinit no se ha inicializado y para lanzar la excepción apropiada cuando se accede a la propiedad.

Para los tipos primitivos, no existe tal valor, por lo que no hay forma de marcar una propiedad como no inicializada y proporcionar los diagnósticos que lateinit necesita proporcionar. (Podríamos intentar usar un marcador separado de algún tipo, pero ese marcador no se actualizará al inicializar el campo a través de la reflexión, que es un caso de uso importante de lateinit ).

Por lo tanto, lateinit se admite para propiedades de tipos de objeto.

Answer 3

Una respuesta corta es que con las primitivas siempre puede usar 0 como valor predeterminado, y con los tipos anulables null como valor predeterminado. Solo los tipos no primitivos no anulables pueden necesitar un lateinit para evitar el sistema de seguridad de tipos.

En realidad, no es necesario inicializar una variable en Kotlin siempre que tenga un valor antes del primer acceso y pueda probarse estáticamente . Lo que significa que este código es perfectamente válido:

fun main(args: Array<String>) {
var x: Int
val y: Double
x = 0
y = x + 0.1
println("$x, $y")
}

Pero hay casos (raros) en los que la inicialización no se puede probar estáticamente. El caso más común es un campo de clase que utiliza cualquier forma de inyección de dependencia:

class Window {
@Inject lateinit parent: Parent
}