4 ms·

I've been using kotlin and swift. They've partly removed null with the 'maybe' feature. So instead of calling methods on null objects the methods are just not

I've been using kotlin and swift. They've partly removed null with the 'maybe' feature. So instead of calling methods on null objects the methods are just not called if the object is null. This helps when there's a race condition, and you attempt to call a method on a null object, and then that solves itself by the same code being called again without the race condition. But a lot of the time if the object is null and the method is not called you still have an error, but it's just not a null pointer error now. This 'nullless' code is nice in some places, especially with UI lifecycles calling code repeatedly, but other times it just changes the type of error you debug.

jillesvangurp 8y ago
Actually in Kotlin, nullability is part of the type system and denoted with a ?. So String and String? are two different types. Dereferencing a nullable type is a compile error until you do the null check. Doing that triggers a smart cast to the non nulled type. So the inferred type becomes non nullable and you don't have to do any casts. You can force this cast by using the operator !!, which you should avoid for obvious reasons but is useful with some legacy code. If you get this wrong you still get an npe. It also provides backward compatibility with java where java types are considered nullable by default unless other wise annotated with a @NonNull. Also you get nice warnings about redundant null checks. This provides for a lot of extra compile time safety and it largely removes the need for Maybe, Optional, and other kludges that people have been coming up with to force programmers to replace null checks with empty checks.