If I have moved a class to a different gradle module, and I have code like so, ```if (it.playables ...

# announcements

[rrva]

If I have moved a class to a different gradle module, and I have code like so,

if (it.playables != null && it.playables.isNotEmpty())

Why does the compiler force me to write

if (it.playables != null && it.playables!!.isNotEmpty())

Due to the fact that

Smart cast to 'List<IdString>' is impossible, because 'it.playables' is a public API property declared in different module

[Desmond Teo]

Alternative will be it.playables?.isNotEmpty() == true

[streetsofboston]

Some other thread that may have access to the instance referred to by it may have changed `it`’s nullable property playbable to the value null just after the it.playables != null check but before the it.playables.isNotEmpty() call.

[rrva]

but how does the nullability guarantees change due to the fact that I am modularizing the code?

[rrva]

it was able to do the smart cast when the code was local to the same module

[streetsofboston]

Maybe the compiler could check if anything was changing the value to ‘null’ or not while it was in the same module…. I must admit, this is a bit mystifying 🙂

[rrva]

I solved it by creating a locally scoped copy

[streetsofboston]

yeah… usually doing something like it.playables?.let { … } will do the trick

[Michael de Kaste]

I see this question coming up a lot of times

[Kroppeb]

The reason is that each module can be compiled seperatly. Now this means that if you compile this snippet and then change playables to be a var instead of a val, or a inconsistent custom getter, this piece of code would still work, as there is still a getter available. However now the guarantee that it.playables is not null is no longer true.

[kqr]

if my dependecy has changed, shouldn't we recompile too?