Is there a plan in the roadmap to make the compile...

# getting-started

[Klitos Kyriacou]

Is there a plan in the roadmap to make the compiler know that b is not null in the following and doesn't require !!?

if (a != null || b != null) {
        if (a == null) {
            val c: Any = b!!
        }
    }

[Casey Brooks]

The logic behind why it’s not working is a bit weird, but the first if-statement would short-circuit if a is non-null and never evaluate the b != null expression, so within that block the compiler doesn’t really have any hard facts about b within that scope.

Doing if (a == null && b != null) instead does give you the smart-cast, and it also removes the extra if-statement.

[Klitos Kyriacou]

Thanks, that's interesting. I can't remove the extra if-statement because the actual structure I was working with was more like:

val a = something...
    val b = something else...
    if (a != null || b != null) {
        // some code...
        if (a == null) {
            // do something with the obviously not null b
        }
        if (b == null) {
            // do something with the obviously not null a
        }
        // some more code...
    }

[Ruckus]

@Casey Brooks Are you sure about that? The short circuiting happens at runtime, so saying the compiler has no information about b seems wrong. The compiler will see the entire expression, and absolutely should be able to infer the truthiness, regardless of what could happen at runtime.

[Ruckus]

There's no reason the compiler couldn't determine "If a == null, this expression didn't short circuit". It's just a matter of complexity of the static analysis.

[Casey Brooks]

Hmm, I guess you’re right.

Either way, though, nested if-statements can be rewritten in a way that keeps them all as a single flat chain of blocks, which is usually much easier to read. Nesting ifs inside ifs quickly gets very difficult to read and trace the logic, especially as the number of variables increases.

A when statement like this can be a good way to model the individual conditions of complex logic:

when {
    a != null && b == null -> { /* only a is non null */ }
    a == null && b != null -> { /* only b is non null */ }
    a != null && b != null -> { /* a and b are both non null */ }
    a == null && b == null -> { /* a and b are both null */ }
}

[Ruckus]

I definitely agree on that front, though depending on the use case (doesn't appear to apply here, but something I've run into), when a and/or b are expressions and not just variables, you either need to extract them to variables or repeat the expressions multiple times, which can sometimes negatively affect readability or scoping as much as the flattening improved it. And that assumes there isn't interspersed logic around the various checks like there is here.

[Ruckus]

@Klitos Kyriacou It could be worth looking into extracting your // some code... and // some more code... chunks out to separate functions, that could then be called in the flattened blocks that @Casey Brooks showed. That could help reduce duplication while still making the logic clear.

[dmitriy.novozhilov]

Actually I think it's possible to add such smartcasts
K2 data flow engine smart enough to operate such constructions
@Klitos Kyriacou could you please file a feature request to youtrack?

[Klitos Kyriacou]

Thanks @dmitriy.novozhilov - I've created https://youtrack.jetbrains.com/issue/KT-62164/Improve-type-inference-to-detect-when-a-value-declared-as-nullable-cannot-be-null