```if (nullableVarParent?.nullableValChildOne == n...

# getting-started

[Ahmed Hassan]

if (nullableVarParent?.nullableValChildOne == null
         || nullableVarParent?.nullableValChildTwo == null) 
      return
    
funcEx(
     nullableVarParent?.nullableValChildOne!!,   
     nullableVarParent?.nullableValChildTwo!!
)
...

I had a discussion with a college about how unsafe the previous code is, to use (!!) operator even after "if condition".
He is totally convinced that the mutable parent is impossible to be null after the if condition since we don't use threads in this area.
His words are some how believable but since everyone in the world has been saying to avoid suppression (!!) in all cases, I wanted to make sure. what do you think might be dangerous about this?

[Rob Elliot]

Just pull out variables for each so the compiler knows?

val nullableValChildOne = nullableVarParent?.nullableValChildOne
val nullableValChildTwo = nullableVarParent?.nullableValChildTwo
if (nullableValChildOne == null
         || nullableValChildTwo == null) 
      return
    
funcEx(
     nullableValChildOne,   
     nullableValChildTwo
)

[Ahmed Hassan]

@Rob Elliot He is not seeing that there is even a problem to fix, not convinced that there is a reason for the code to be changed, so he is not looking for solutions more than reasons

[Rob Elliot]

1) You are now relying on a human being’s understanding of the code and how it is called, and human beings make mistakes. One of the main points of a static type checker is to offload that work onto a computer that doesn’t.
2) Even if you’re right now, what about when someone changes the code in 3 years’ time and does update that var asynchronously? Will they spot that that bit of code just became unsafe?
3) If you do use !! then you either need to add an @SuppressWarnings annotation, which is noisier than the refactor to make the type system happy, or get in the habit of ignoring warnings, which is a root of evil.

There are times when the static type checker is not clever enough, and we need overrides in the form of unchecked casts & not null assertions, but to use them when there’s a trivial way of making the type checker happy is silly.

[Klitos Kyriacou]

How do you get warnings for using !!? I would like to have such warnings too, but I don't see it in the Inspections menu.

[Rob Elliot]

You’re right… I could have sworn I used to get warnings from IntelliJ when using !!. But I don’t now. I’d like to think something has changed, but perhaps I just imagined it… 😳

[Michael de Kaste]

At my work, I've introduced a "withNoNulls" method that I use mostly in these situations

withNoNulls(nullable1, nullable2) { notNull1, notNull2 -> notNull1 to notNull2 } ?: return

makes for very understanding syntax and is scalable

inline fun <R, A, B> withNoNulls(p1: A?, p2: B?, function: (p1: A, p2: B) -> R): R? =
    p1?.let { p2?.let { function.invoke(p1, p2) } }

perhaps you CAN convince your colleague to use that and the problem would be inherently solved?