Is there a way to write code in such a way that th...

# announcements

[Pacane]

Is there a way to write code in such a way that the kotlin analyzer wouldn't complain about these variables being nullable? I'm paraphrasing my code here, but it looks like this

val a: String? = ...
    val b: String? = ...

    if (listOf(a,b).any { it == null }) {
      return
    }
    
    val l = a.length // compiler complains here

Basically I'm doing null checks in for a bunch of variables before doing something with them. Shouldn't the compiler know about a on the last line, not being null?

[diesieben07]

The compiler cannot know that the variables won't change between you checking them and you using them. They might be changed by a different thread or they might even have custom getters - That is why no smart casting takes place. If you want smart casting, you need to store them in a local variable first.

[Marc Knaup]

They’re val s, they cannot change.
The problem here is that the null check is way too complex for the compiler to understand.

[Vampire]

Pretty unlikely that a val is changed by anything, isn't it?
The problem is, that the compiler is not that smart to see the connection between the elements you added to the list being all null-checked.
If you would do if (a == null || b == null) { return } the smart-casting is done just fine.

[Pacane]

yeah I expected that

[chermenin]

val a: String = … ?: return ?

[Pacane]

but I was wondering if
a) the compiler should know about it
b) is there a way to write, maybe an extension method so that the compiler knows about it

[Marc Knaup]

There aren’t many options here.
a) if (a == null || b == null) return
b) a?.let { b?.let { your code } }

[Pacane]

@chermenin I guess that could be an option

[Marc Knaup]

@Pacane how many variables are we talking about? 😄

[bezrukov]

another option is just use ?: in assignment

val a = ... ?: return
val b = ... ?: return

val l = a.length

[Pacane]

@Marc Knaup The current pattern we have in our code is like 10 variables per call site

[Pacane]

we have many call sites where there's just a bunch of null checks like you showed in your a) solution

[Pacane]

it's just a lot of repetitions... but yeah

[Pacane]

I was wondering if we could refactor this thing to an extension method that'd do null checks on a list of variables instead

[Davide Bertola]

it's strange that you have 10 optionals around

[Pacane]

they're coming from external services

[Marc Knaup]

It’s difficult to find the best course of action with a synthetic example.
Can you provide a real example? Maybe there are different options.

[Pacane]

+ I didn't write the code 😛 I'm just code reviewing

[streetsofboston]

If you have an occurring pattern of needing to check more than 1 nullable values for not being null, you could a bunch of overloaded let or guard functions. E.g.

inline fun <A: Any, B: Any, R> let(a: A?, b: B?, block: (A, B) -> R): R {
    return if (a != null && b != null) block(a, b) else null
}

// overload this one for three params, 4 params, 5 params, etc, as much as you need)

[Pacane]

right

[Pacane]

here's one example we have

var site = parsed.tags["site"]
            val asset = parsed.tags["asset"]
            val field = parsed.fields.first().fieldKey
            val value = parsed.fields.first().fieldValue

            if (site == null || asset == null || field == null || value == null) {
              continue
            }

[Pacane]

in another call site, it's exactly the same thing, but we're checking if it's null or empty

[Marc Knaup]

@OptIn(ExperimentalContracts::class)
inline fun anyNull(a: Any?, b: Any?, c: Any?): Boolean {
    contract {
        returns(false) implies (a != null && b != null && c != null)
    }

    return a == null || b == null || c == null
}

Usage:

if (anyNull(a, b, c)) return

[Pacane]

my provided solution was this

[Pacane]

fun<T> List<T>.anyNull() = this.any { it == null }
fun List<String?>.anyNullOrEmpty() = this.any { it.isNullOrEmpty() }

[Marc Knaup]

@Pacane why not use the ?: return approach?

[Pacane]

because in the second call site we want to check if null or empty

[Pacane]

does that operator cover the empty string case?

[Davide Bertola]

v.takeIf { it.notEmpty() } ?: return null

[Marc Knaup]

You can make your own function and also check for empty string, yes

[diesieben07]

RE: "They are val's they cannot change":
val foo: Int get() = Random.nextInt() Tada, your val is changing.

[Marc Knaup]

@Pacane

@OptIn(ExperimentalContracts::class)
inline fun anyNullOrEmpty(a: String?, b: String?, c: String?): Boolean {
    contract {
        returns(false) implies (a != null && b != null && c != null)
    }

    return a == null || b == null || c == null || a.isEmpty() || b.isEmpty() || c.isEmpty()
}

[Marc Knaup]

@diesieben07 getters aren’t allowed for local val s 🤔
But delegation may be an issue.

[diesieben07]

Maybe I have not understood the problem here.

[Vampire]

It is about local variable `val`s, not property `val`s

[Vampire]

If you have a custom or open getter smart casting does not work anyway

[Vampire]

And in case of delegation, smart casting also does not work due to the same reason

[Nir]

I feel like contracts are ultimately supposed to allow you to write a custom function that would solve this, similar to what Marc wrote

[Pacane]

yeah and I've been trying to see if there's something in there that'd allow me to use an arbitrary amount of arguments instead of hard coding a fixed amount

[Nir]

Without contracts there are always going to be limits to what the compiler can infer; each time you extend the compilers ability to infer a certain condition, you can come up with a more complex condition where it fails

[Marc Knaup]

@Pacane you can write the function for 20 parameters and simply use default arguments to allow for less than 20.

[Pacane]

yeah that'd be a way

[Nir]

Contacts are experimental though, right? You can use them?

[Pacane]

I wish there were some kind of construct in there that'd deal with lists lol

[Pacane]

oh we're balls deep in optIns by now 😛

[Marc Knaup]

Using a list for that is weird. It just adds overhead for no real benefit 🤔

[Marc Knaup]

I also don’t care about experimental annotations in ANY project 😄

[Pacane]

yeah, I might use the 20 arguments thingy

[Pacane]

I was just wondering

[Nir]

Hmm contracts can't assert that a lists elements are non nullable?

[Nir]

You can't accept a x: List<String?> and say returns false implies that x is List<String> ?

[Nir]

@Marc Knaup the real solution is variadic generics but I wouldnt hold my breath :-)

[Pacane]

First time I hear about those 🙂