casting - example - ¿Por qué Kotlin no realiza el moldeado automático de texto?
nullpointerexception kotlin (3)
Kotlin no permite conversiones implícitas de tipos numéricos. Existe un concepto erróneo de que las conversiones implícitas son " sin daño, sin falta " ... lo cual es incorrecto.
El proceso en Java para las conversiones implícitas es más complicado de lo que cree, lea los documentos para ver qué implica todo esto. Y luego puede tratar de analizar todos los casos que pueden salir mal.
Kotlin, no quiere que el compilador adivine su intención, por lo que hace que todo en el lenguaje sea explícito, incluidas las conversiones de tipo numérico. Como se explica en los documentos de Kotlin para conversiones explícitas , dice claramente:
Debido a las diferentes representaciones, los tipos más pequeños no son subtipos de los más grandes. [...] Como consecuencia, los tipos más pequeños NO se convierten implícitamente a tipos más grandes. [...] Podemos usar conversiones explícitas para ampliar números.
Y la documentación muestra una de esas muestras de donde las cosas pueden salir mal, pero hay muchas otras.
Tampoco puedes simplemente lanzar un tipo numérico a otro, como se menciona aquí en comentarios y respuestas incorrectos. Eso solo dará como resultado un buen error de tiempo de ejecución. En su lugar, observe las funciones de conversión numérica como toInt() y toDouble() encuentran en los tipos numéricos, como en la clase Number .
La expresividad es parte de la personalidad de Kotlin, y no está previsto que cambie.
var a : Double
a = Math.sin(10) // error: the integer literal does not conform to the expected type Double
a = Math.sin(10.0) //This compiles successfully
println(a)
¿Por qué no kotlin realiza una conversión de tipo implícita y nos obliga a pasar el tipo exacto de datos?
fun sin(value: Double): Double // at kotlin documentation
La conversión automática de tipos para tipos numéricos puede llevar a perder precisión. Simplemente considere seguir el código de Java:
double hoursSinceUnixEra = System.currentTimeMillis()/1000/60/60;
La intención no era cortar el resultado a horas completas, aunque se compila sin ninguna advertencia en Java.
val hoursSinceUnixEra = System.currentTimeMillis()/1000/60/60;
someObject.doubleValue = hoursSinceUnixEra
El código de arriba de Kotlin no se compilará debido a un lanzamiento no explícito.
El problema de este tipo puede ser muy difícil de encontrar y solucionar, y es la razón de esta decisión. Todavía puede convertir explícitamente tipo:
val value = 3
Math.sin(value.toDouble())
Todos sabemos que Kotlin tiene tanto Int no anulable como Nullable Int? .
Cuando usamos Int? esto sucede: Kotlin en realidad ''recuperó'' primitivas JVM cuando Kotlin necesita una referencia anulable, ya que está destinada a eliminar el peligro de referencias nulas desde el código.
Ahora mira esto: (suponiendo que este sea un código compilable)
val a: Int? = 1
val b: Long? = a
Kotlin no realiza la conversión de tipo implícita debido a que esto sucede. Si Kotlin realizó conversiones de tipo implícitas, b debería ser 1 . pero como a es un recuadro Int b es un recuadro Long , a == b da como resultado false y cae en contradicción, ya que su == operador verifica que equals() y Long equals() verifique que otra parte sea Long también .
Verifique la documentación: