3 ms·

Is there something that you can express with Option that you cannot express with a nullable type?

• _Codemonkeyism 10y ago
  For me nullable type expresses something semantically different than Option. Option is a higher concept expressing optionality - duh ;-) - contrived example - it might make semantical sense to express Option[Option[A]] as a type, it does not make sense to have wrapped nullable types (except as a result of nested function calls). Nullable types feel like a bugfix to null, Options fell like a concept to model business domains. Same as None expresses something different (not there) than null (usually e.g. in Java conflating not there with not initialized). With Option it also makes sense to have flatMap, for comprehensions etc.
  • realharo 10y ago
    I think you're only meant to use nullable types in Kotlin for exactly that purpose - expressing a value that may or may not be there (aside from the compatibility with Java libraries of course). For things that just cannot be initialized directly in a constructor, you have more idiomatic constructs, such as the `lazy` property delegate, or in the worst case, the `lateinit` keyword (though at that point it may be better to rethink the design of your interfaces). For indicating that an error occurred, you have exceptions.
• aninhumer 10y ago
  There are many things you can express with ADTs that you can't express with nullable types, and once you have those, Option is simpler than extending the type system. EDIT: Another thing you can do with Option is define generic abstractions that work on it and other types, like map/flatMap. This in turn means you can write generic functions over anything that can be flatMapped which work automatically for Options. (I don't know if there's anything equivalent in Kotlin though?)