I am starting with Kotlin and trying to understand something.
var foo: String = null does not compile as expected.
var foo: String? = null should be the correct syntax and compile as expected.
So why does var foo = null compile??
The type of foo in this case will be inferred to Nothing?, which is a very special type. In short, Nothing is a type that is a subtype of every type in Kotlin (therefore Nothing? is a subtype of every nullable type), has no instances, and can be used as a return type for functions that can never return.
Even though Nothing can have no instances, null itself of type Nothing?, which is why it can be assigned to any nullable variable.
You can learn more in depth about Nothing in the official docs, in this excellent Medium article, and in this article that covers the overall Kotlin type hierarchy.
For var foo = null, the type is inferred to Nothing?, and is therefore valid syntax.
var foo = null is equivalent to var foo:Nothing? = null
similarly
var foo = "" is equivalent to var foo:String = ""
and slo
var foo = 1 is equivalent to var foo:Int = 1
The compiler is smart enough to infer the type of foo from the right hand expression type.
Related
I expected that the type of a variable is promoted to a non-null type after a not-null check (like in the Dart language).
val someMap = mapOf("a" to 0L)
val a = someMap['a'] // a is of type Long?
if (a != null) {
val b = a // b is of type Long? and not of type Long. Why?
}
Can someone explain why this is not the case? Just a matter of taste of the language designers?
Since there is smart-casting, it doesn't matter. It will allow you to use members of a or b inside the if statement without null-safe calls (?.) or null assertions (!!). You can also safely declare b to be a Long without the compiler complaining:
if (a != null) {
val b: Long = a
}
It is I think a design choice for how implicit types should be inferred that b's type must be explicitly declared if you want it to be considered non-nullable. This is only relevant if passing it to a function with generics, since there is smart-casting.
What you can do instead of explicit null check is using let{} as follows:
val someMap = mapOf('a' to 0L)
val a = someMap['a'] // a is of type Long?
a?.let {
val b = it // b is of type Long
}
It is called smart casting, basically Kotlin is smart enough to determine that variable can no longer be null after check. More detail and can be found here if you are interested
As to why, only the creators of kotlin can know. But what you can do is this if you want a Long instead of Long? there is this
val b = a!!
example:
fun main(){
var userInput: String?
//userInput = null
userInput = "asbdef"
var inputLength:Int? = userInput!!.length
println("Length of the string is :"+inputLength)
}
Output :
Length of the string is :6
fun main(){
var userInput: String?
userInput = null
//userInput = "asbdef"
var inputLength:Int? = userInput!!.length
println("Length of the string is :"+inputLength)
}
Output :
Unresolved reference: length
I want to know why it gives compile error?
If I just replace (!!) operator with (?) it compiles well but prints output as null.
PS: I'm newbie in Kotlin
The ?. operator short-circuits if the left side evaluates to null. So the result of nullVariable?.length is null and .length is never evaluated. Your first example is effectively doing:
println("Length of the string is :" + null)
The !! operator says "throw a NullPointerException if the left side is null. Otherwise, we know it's not null on the right side". You can see this if you change your second example a little:
val userInput: String? = null
val inputLength:Int = userInput!!.length // throws NullPointerException
However, I'm not sure why are you are getting Unresolved reference: length. It looks like that the compiler is doing some optimization when you assign null directly to userInput, so rather than compiling it to a String? which throws an NPE at runtime, it knows the value is only null (not String?) at compile time, and therefore can't have the length property because null is not a reference.
You can force it to give you to NullPointerException by adding a layer of abstraction via a function call:
fun main(){
var userInput: String? = "foo"
userInput = alwaysNull()
val inputLength:Int = userInput!!.length // NullPointerException
}
fun alwaysNull(): String? = null
I don't see anything n the Null Safety documentation about the difference in behaviour between initializing in one line / via a function call vs. assigning null directly to a var though, so what's happening under the hood to get Unresolved reference is just a guess.
Let's say I have a set of two pojo's like so:
data class Test (
var id : Long? = null
)
data class TestOther (
var id : Long = 0,
var isCool : Boolean = false
}
and then I have an infix function like so:
infix fun <T : Any?> KProperty<T>.equal(rhs : KProperty<T>) = BinaryExpression<Boolean>(this, rhs, EQUALS)
then this works fine as I'd expect:
Test::id equal TestOther::id
but so does this, since T is all types that extend Any?:
Test::id equal TestOther::isCool
Is there anyway to specify generic constraints such that nullable and non nullable types can be compared, but objects of different types cannot without having to specify an overload for every possible concrete type?
It is not possible to do right now. You may follow the issue for more details
https://youtrack.jetbrains.com/issue/KT-13198
I see a workaround here (similar to the one from the issue). The idea is to wrap the KProperty<R> into a wrapper class without variance. As you see, the KProperty type has out R variance, which works against us in the example. You may follow the link for the details on the declaration-side variance in Kotlin
https://kotlinlang.org/docs/reference/generics.html#declaration-site-variance
The workaround works as strict as expected
class KWrapper<R>(val p : KProperty<R>)
infix fun <T : KWrapper<R>, R> T.equal(rhs : T) = false
val <T> KProperty<T>.wrap get() = KWrapper(this)
val a = Test::id.wrap equal TestOther::id.wrap //fails: Long vs Long?
val b = Test::id.wrap equal Test::id.wrap //works
val c = Test::id.wrap equal TestOther::isCool.wrap // fails Long vs Boolean
The downside is that you need to use .wrap extension property (or extension function) for the left and right parameters separately
Take a look at this kotlin one liner:
val nonNullArr : List<NonNullType> = nullArray.filter {it != null}
The compiler gives a type error at this line, saying that a list of nullables can't be assigned to a list of non-nulls. But the filter conditional makes sure that the list will only contain non null values. Is there something similar to !! operator that I can use in this situation to make this code compile?
It seems logical to assume that the compiler would take into account the predicate
it != null
and infer the type as
List<NonNullType>
but it does not.
There are 2 solutions:
val nonNullList: List<NonNullType> = nullableArray.filterNotNull()
or
val nonNullList: List<NonNullType> = nullableArray.mapNotNull { it }
As far as I know, you cannot convert nullable types into nonNull types by just verifying that they are not null. To achieve what you want, you need to manually map nullable values to non-null type by simply creating NonNull type object. For this you can use map extension function.
val nullableArray: Array<String?> = arrayOf("abc", "xyz", null, "efg")
val nonNullList: List<String> = nullableArray.filter { it != null }.map {
it.toString()
}
Or you can use filterNotNull() method as #forpas suggested in comments
val nonNullList: List<String> = nullableArray.filterNotNull()
Hope it helps you!
You can't assign a nullable type to a non-nullable type of value.
The type-matching maybe works when you assign a value, not after filter operation called.
// the type-matching works before `.filter` is called
val nonNullArr : List<NonNullType> = nullArray//.filter {it != null}
instead, if you want to do this without an error or without concerning the type. Remove the type from the val, so it goes like this
val nonNullArr = nullArray.filter {it != null}
Hope it helps
try using listOfNotNull instead of listOf(), it is equivalent to list.filterNotNull()
Please help me understand this piece of code in the kotlin docs:-
val a: Int = 10000
print(a === a) // Prints 'true'
val boxedA: Int? = a
val anotherBoxedA: Int? = a
print(boxedA === anotherBoxedA) // !!!Prints 'false'!!!
Now, I understand that first int a = 10000 then in the next line it is comparing it using ===.
Now the question is why when it assigned boxedA=a, it checked if it is null using int?. Can it just be written like this:-
val boxedA: Int=a
Please if I'm understanding it the wrong way, someone guide to check the right place or explain it a bit for me.
First, the Int will be mapped to java int/Integer depending on its context. If Int is a generic argument, then its mapped type is Integer. Otherwise, it is a primitive type int. for example:
val a:Int = 1
//final int a = 1; //mapped to java code
val numbers:List<Int> = asList(1,2,3)
//final List<Integer> numbers = asList(1, 2, 3); //mapped to java code
Secondly, boxing an Int to an Int? is same behavior as java boxing an int to an Integer, for example:
val a:Int = 1 // int a = 1;
val b:Int? = a; // Integer b = a;
Why the boxed Integers are not the same?
This is because Integer only caching values in the range [-128, 127]. the the variable a above is out of the cache range, it will create a new Integer instance for each boxing rather than using a cached value. for example:
// v--- 1 is in cache range
val ranged: Int = 1
val boxedRanged1: Int? = ranged
val boxedRanged2: Int? = ranged
println(boxedRanged1 === boxedRanged2) //true
// v--- 128 is out of cache range
val excluded: Int = 128
val boxedExcluded1: Int? = excluded
val boxedExcluded2: Int? = excluded
println(boxedExcluded1 === boxedExcluded2) //false
when it assigned boxedA = a, it checked if it is null using int?
I have no idea what you mean by this. Making a variable have the type Int? makes it a variable that can either store an Int or null. There is no checking happening at this assignment. If you have a non-null value to assign to the variable, just make it non-nullable, without the ? in the type:
val copyOfA: Int = a
You can even omit the type, and get Int inferred:
val copyOfA = a
As for the comparisons:
== is used for comparing by value in Kotlin (this is the equivalent of using equals in Java), === is used for comparing references (this is == in Java).
When you create boxedA and anotherBoxedA, you create two Integer instances under the hood (because nullable variables can't be represented by primitives). These will be equal when compared with == (they have the same value), but not when compared with === (they are different instances).
You can see the relevant part of the offical docs here.
it checked if it is null using int?
That is not what it means.
Kotlin's null safety feature does not allow a variable to be set as null by default.
Check here.
val anotherBoxedA: Int? = a
This means that anotherBoxedA can be assigned null or is nullable.
val anotherBoxedA: Int? = null
This will be allowed.