![]() ![]() ConclusionĪlthough I appreciate the effort of making some abstract Functional Programming ideas a bit less abstract regarding naming conventions (for example, takeIf() instead of filter()), I’d still feel more comfortable working with standard maps and flatmaps used by the rest of the functional world. Error:(19, 9) Kotlin: Only safe (?.) or non-null asserted (!!.) calls are allowed on a nullable receiver of type String?īut if we perform a null-check first, we get a green light from the compiler: if (foo2 != null) // filter() ?: 42 // orElseGet() 4. The striking thing happens if we try to call a method/field on the second one – the code doesn’t compile: foo2.length So, that’s non-nullable String: val foo : String = "42"Īnd this one is nullable: val foo2 : String? = "42"Īs simple as it is. ![]() Simply put, each type is non-nullable by default but can be made nullable by appending the question mark to the type name. Kotlin implemented its approach to null-safety that can leverage extra compiler support. If you’re familiar with Kotlin’s approach to null-safety, feel free to skip this section with no regrets. Let’s see how does its native approach to null-safety compare to. Kotlin truly shines when it comes to avoiding excessive bureaucracy of classical Type-Driven approaches to optionality.
0 Comments
Leave a Reply. |