Hello people :slightly_smiling_face:! In our compa...

# announcements

[Nick]

Hello people 🙂! In our companys closed chat we have been arguing with kotlin developers about how is it safe to remove intristics calls with proguard in release builds.
I think that removing this checks brings undefined behaviour, because method body will start to execute before potential NPE, for example:

fun f(a: String){
  sendData()
  //some a.length call (throws NPE)
}

with intrictics removed 'sendData' method will be executed.

Another persons position is that business logic should be explicitly checked with some require(a!=null) check and developers should not rely on intrictics.

What do you think?

[Adam Powell]

explicitly null checking non-nullable parameters is deeply silly. If you're not confident enough in the code to run with scissors on this, don't remove the intrinsics checks 🙂

[Adam Powell]

if the codebase is kotlin only you can count on the compiler having null-checked things for you in advance already; if you have mixed in java callers then those checks might be buying you some correctness

[jw]

you can remove intrinsics with a compiler flag, no proguard needed. that being said, it sounds like you're doing Android in which case the framework is written in Java and has no validation of nullable values. it will likely be the source of all the unexpected values.

unless you've measured the intrinsics to be a performance or APK size problem, they're probably not worth removing