Estaba siguiendo la documentación de Kotlin en http://kotlinlang.org/docs/reference/null-safety.html#checking-for-null-in-conditions y traté de adaptar este ejemplo,
val b = "Kotlin" if (b != null && b.length > 0) { print("String of length ${b.length}") } else { print("Empty string") } al caso donde b = null . En un proyecto IntelliJ Idea Kotlin tengo un app.kt con una función main() definida como:
fun main() { val b = null if (b != null && b.length > 0) { print("String of length ${b.length}") } else { print("Empty string") } }Sin embargo, cuando ejecuto esto, obtengo dos errores de compilación:
Information:Kotlin: kotlinc-jvm 1.3.20 (JRE 11+28) Information:2019-02-02 15:07 - Compilation completed with 2 errors and 0 warnings in 1 s 921 ms /Users/kurtpeek/IdeaProjects/HelloWorld/src/app.kt Error:(3, 24) Kotlin: Unresolved reference: length Error:(4, 37) Kotlin: Unresolved reference: length Entiendo que el compilador está evaluando b.length aunque la primera condición, b != null , es false . Esto me sorprende porque pensé que la primera verificación era 'cortocircuitar' la expresión booleana si era necesario y hacer que la llamada a b.length 'segura'.
Por ejemplo, en Python, puedes hacer esto:
In [1]: "foo" == "bar" and what.the.heck Out[1]: False que funciona aunque what que no está definido, porque el and 'se detiene' ya que "foo" no es igual a "bar" .
¿Es realmente así como funciona Kotlin? Parece que perder la característica de 'cortocircuito' de Python sería una limitación.
El operador && de Kotlin provocará un cortocircuito (al igual que el de Java), pero solo en tiempo de ejecución. Lo que está experimentando es un error de tiempo de compilación . La gran diferencia que hay que recordar, especialmente cuando se compara Kotlin (o Java) con Python, es que Kotlin y Java se escriben estáticamente y tienen una fase de compilación. Entonces obtendrá un error de compilación si los tipos no coinciden.
Vamos a repasar estos uno a la vez...
val b = "Kotlin" if (b != null && b.length > 0) { ... } En este caso, Kotlin inferirá correctamente que b es del tipo String , porque claramente lo configuraste como String ("Kotlin"). Debemos tener en cuenta aquí que el tipo String nunca puede contener nulo. Sabiendo eso, la parte b != null de su declaración if es innecesaria. Sin embargo, después de evaluar eso (a true, siempre) evaluará b.length porque b es una String y, por lo tanto, tiene una propiedad de length . Este ejemplo debería compilar bien (no lo probé).
Y después...
val b = null if (b != null && b.length > 0) { ... }Este código no se compilará, repasemos por qué...
Este código se ve muy similar pero tiene una gran diferencia. En este caso, debido a que simplemente establece b en null , Kotlin va a inferir que b es un Nothing? . No tiene información sobre qué tipo desea que b sea, y lo configuró en nulo (y debido a que es un val , siempre será null ). Debido a que b es null , hace que b sea anulable.
Entonces, dado que, cuando compilamos b != null , eso siempre fallará, porque b nunca puede ser algo que no sea null . ¡Pero espera! Estamos compilando ahora... y cuando nos encontremos con b.length , Kotlin arrojará un error de compilación porque Nothing? no tiene una propiedad de length !
Esencialmente, al establecer b en null y no proporcionar una sugerencia de tipo, Kotlin toma el único camino que puede para inferir el tipo: Nothing? .
De su texto vinculado: "Tenga en cuenta que esto solo funciona donde b es inmutable (es decir, una variable local que no se modifica entre la verificación y el uso o un valor de miembro que tiene un campo de respaldo y no se puede anular)".
val b=null es inmutable, pero dado que el tipo de nulo no se puede inferir ni almacenar, no se puede usar como fuente en un atajo válido.
Si cambió el código para darle un tipo anulable y estableció ese nulo, esto funcionaría.