you should know better than the compiler :slightly...

# announcements

[bod]

you should know better than the compiler 🙂

[jkbbwr]

No you shouldn't compilers are better at problem solving than humans when the problem is defined properly.

[karelpeeters]

Something something dynamically typed languages 😛.

[bod]

A compiler is a very basic tool. The human brain of a developer is smarter. Jetbrains knew this when they specified Kotlin and decided !! would be useful 🙂

[bod]

Same with annotations or other mechanisms that allow to ignore warnings. Because a developer is smarter than a static analysis tool.

[Shawn]

just because the compiler generate warnings that aren’t appropriate in 100% of all edge cases doesn’t mean developers are smarter

[Shawn]

humans make plenty of mistakes and misinterpret things literally all the time

[Shawn]

really “smarter” isn’t a useful term here since it implies we’re talking about more general-purpose kind of intelligence. in a restricted domain with a properly defined problem space (crazy example: compiling a programming language), the machine will get it wrong far less than the person will

[cedric]

Even if occasionally I know for sure something can't be null but the compiler doesn't, I'll throw in a null test else throw some exception

[karelpeeters]

That's basically the same as !! though.

[cedric]

Except I can make the exception more meaningful

[cedric]

If I feel really confident, I'll just ?.let { nonNullableVal

[cedric]

but I'm always a bit wary of ?.let because it's an if without an else, and this has the potential to hide bugs

[groostav]

we've got a couple of objects on our code-base that are used in such a way where they may have nullable fields and then at some point our business logic means that those fields cant be null. most of the time, similar to cerdric, I'll throw a require(we.someProp != null) { "msg with domain significance" } infront of the methods in question.

validation on a POJO (data-class) seems to be a pretty obvious example. If you've got a validator and a service that expects only objects passed by the validator, and you dont want to map from a nullable-POJO to a non-nullable one your service is likely to be implemented with some pojo.someProperty!!.

[gildor]

require(we.someProp != null) -> requireNotNull(we.someProp)

[bod]

Regardless of what "smart" means, really my point was that I don't think !! should be considered a code smell 🙂 Sometimes you just know with 100% certainty that a variable cannot be null, and testing its nullity will add noise (and possible confusion) to the code - that's when !! does absolutely make sense, and should be encouraged 🙂 Well that's my personal opinion about it anyway and I can understand if some people disagree 🙂