4 ms·

It gives you a type/interface level guarantee. e.g. you know public Optional<File> loadFile(String filename); can fail to return a file, while publi

It gives you a type/interface level guarantee. e.g. you know public Optional<File> loadFile(String filename); can fail to return a file, while public Int sum(Int a, Int b); can't fail to return an Int. Obviously, because nulls exist in java, this guarantee isn't provable on compilation the way it is in e.g. Scala, but if your entire team writes code this way, at least you can rely on that for internal libraries. Like generics, this is one of those ideas that's ok in java 1.X, but doesn't shine as much until a backwards incompatible java 2.X

eropple 10y ago
Nulls exist in Scala. You can return null for an Option[T]. Can't in Kotlin, though.
- kodablah 10y ago
  When interoperating with other libraries on the JVM you very easily can, which is a very common use case.
  - eropple 10y ago
    You're right. Kotlin provides the null-or-throw operator (!!) to convert a Derp? into a Derp, though.
deleted 10y ago
[deleted]
Filligree 10y ago
Nullable types provide Optional already. I find the use of a custom wrapper type to be a massive wart, and Optional is a common enough thing that it's worth adding a bit of syntax for it. Which is why I like Kotlin's approach. Same guarantees, one letter instead of ten. If you're writing Java, though, I can see why Optional has some use.