Why do people keep saying "kotlin is null safe, oh my god it's so safe, you don't have to worry about null's...". when all you have to do is add a question mark and BAM null-city!

Sounds simar to the new null annotation for C#8.

But doing this will give you compiler warnings/errors when passing a possible null value, right?

Because it's null-safe by default, and the ? operator simply turns off this null safety to allow you to interface with legacy / non-type safe code. That doesn't make it "null-unsafe", in the same way casting doesn't make a language "type-unsafe".

If adding this operator isn't something you should allow in your codebase, you can easily create a linter rule and/or pick this up in code review.

"I have a lock in my door, but if I leave it unlocked everyone can enter, therefore this lock is not safe."

Also people don't keep saying this, it's been like a year since i heard someone use this as an argument for kotlin. (i mean you can use @nullable and @nonnull with java and a good linter).

I can see Kotlin was trying to do something to avoid all those null checks and NPEs but to me it just appears all they have done is introduce a lot of fluff for dealing with nulls. When I see people defend it, perfect example is @gronostaj lock analogy, it's not really a good defence (I honestly mean no offence). If you're designing a safe lock which won't let people in then don't add potential design flaws! Whether or not you use the '?' your design still has to take into consideration when a reference may be null.

But Kotlin _does_ force you to handle nulls explicitly (with the exception of interaction with Java code). If a value is nullable (uses ?), you have to handle the null case every time you're using it where a non-nullable counterpart is expected. This completely solves the NPE problem known from Java which was caused by types implicitly accepting nulls which could not be handled properly.

It's actually documented pretty well here: https://kotlinlang.org/docs/...

There are only 4 cases where NPEs are possible in Kotlin:

- throwing them yourself (obviously)

- interacting with Java (unavoidable, since you don't know if value passed to Java is supposed to be nullable; also all values coming from Java are potentially nullable but maybe not)

- explicitly saying "screw you Kotlin, I want to be null-unsafe here and if something goes wrong it's not your fault"

- the only _actual_ reason for NPEs in pure Kotlin: messed up object initialization

if (nfcAdapter == null || !nfcAdapter?.isEnabled!!) {

soooooooooooooooooooo ugly :(

My Kotlin skills are rusty, but IIRC after the null check the compiler treats the value as non-nullable.

Only if it's immutable

I'd just like to add, I'm loving some of the other syntactic sugar. Shame java not catching on quick enough.

@TedTrippin bit late, but !(nfcAdapter?.isEnabled ?: false)

@gitreflog thats nicer, thx :)