Is it possible to tell the Kotlin compiler that a ...

# getting-started

[hho]

Is it possible to tell the Kotlin compiler that a method returns null only if the input parameter is null? By an annotation or a contract?

[Youssef Shoaib [MOD]]

fun foo(x: Type): ReturnType
fun foo(x: Nothing?): ReturnType?

[Youssef Shoaib [MOD]]

or use Type? instead of Nothing?

[hho]

That's genius, thank you!

[ephemient]

https://github.com/JetBrains/java-annotations/blob/master/common/src/main/java/org/jetbrains/annotations/Contract.java does support

@Contract("null -> null, !null -> !null")

which may be used by IDE inspections, but the Kotlin compiler doesn't make use of it

[ephemient]

with the built-in kotlin.contracts, you can write

@OptIn(ExperimentalContracts::class)
fun foo(x: T?): U? {
    contract {
        returnsNotNull() implies (x != null)
    }

but that probably doesn't give you what you want ((x != null) implies returnsNotNull() is not possible)

[ephemient]

Youssef's suggestion works for literal null, but not for values of nullable type

[Youssef Shoaib [MOD]]

Yes I forgot about that initially, but my suggestion to use Type? should therefore do the trick

[Youssef Shoaib [MOD]]

And the compiler will choose the non-nullable version if the type is smartcast to be not null

[ephemient]

well, not quite: they both have the same method signature, so you need to disambiguate

[hho]

yeah, I just found that out 😞

[hho]

I was looking for something like the @Contract annotation, but with smartcasts as a result…

[Youssef Shoaib [MOD]]

@JvmName("fooNotNull") does the trick I believe

[ephemient]

I'd probably

fun foo(x: Any): Any { ... }

@JvmName("nullableFoo")
fun foo(x: Any?): Any? = if (x != null) foo(x) else null

since it's slightly easier to smart-cast to non-nullable to call the right overload, than it is to go the other way, but yeah

[Youssef Shoaib [MOD]]

Depends though since there might be some setup/teardown side-effect that the function does regardless of the nullability of the parameter. Also, if that truly is the case that the function just immediately returns null if the input is null, then it really shouldn't be an extension on nullable, and instead one should use ?. when calling it

[ephemient]

well sure, it's pretty useless in this example form, I assume Henning has some other purpose for it

[ephemient]

but going the other way

fun foo(x: Any?): Any? { ... }

fun foo(x: Any): Any = foo(x as Any?)!!

is just plain uglier IMO

[hho]

I'm just stupid … I use it with generics, and that of course can't work at all:

fun <T> newVariable(value: T?): Variable<T>? = value?.let { Variable(it, null, null) }

[Youssef Shoaib [MOD]]

Well... You can, but you just end up specifying the non-null constraint in the type param instead (playground):

fun main() {
    val kotlin = "🙂"
    println(newVariable(kotlin))
    val nullableKotlin: String? = null
    println(newVariable(nullableKotlin))
    val nullableKotlin2: String? = kotlin
    println(newVariable(nullableKotlin2))
}
data class Variable<T>(val value: T, val second: String?, val third: Int?)
@JvmName("newVariableNullable")
fun <T> newVariable(value: T?): Variable<T>? = value?.let { Variable<T>(it, null, null) }.also { print("nullable: ") }
fun <T: Any> newVariable(value: T): Variable<T> = Variable(value, null, null).also { print("non null: ") }

prints:

non null: Variable(value=🙂, second=null, third=null)

nullable: null

nullable: Variable(value=🙂, second=null, third=null)