Hacker News Reader

Comment by awestroke | Hacker News Reader

Sounds like a useless feature in that case

Java has Optional<T> which is actually nullable, unlike the C++ std::optional (which is a value type, not a pointer). So even if it were nullable, it seems that people find value in expressing "This may not return a valid object, you need to check" as an actual object type is useful.

https://docs.oracle.com/javase/8/docs/api/java/util/Optional...

They plan to sort out that problem when value types are finally part of the JVM.

I wish and hope that, in some future version of the Java language, they will change the behavior of Java references so that they are explicitly non-null by default, and require an annotation or signifier of some kind to mark them as nullable.

The Kotlin language (JVM-based) got this right: https://kotlinlang.org/docs/reference/null-safety.html

In the meantime, Java coding best practices dictate treating all references as non-null in first-party code (defensively checking references received from third-party code, such as with Objects.requireNonNull), and avoiding nullable references in favor of Optional.

This won't happen. But Java is likely to get value types, which would be non-null just as in other languages with value types.

The issue of Optional<T> being nullable is an extremely uncommon one - I have seen it happen once ever, and there were way bigger issues going on that happened to manifest that way. It's one of those "that's dumb but ultimately makes no difference" problems that many languages have.

In case, what do you say about returning a class instance from a function in Java? Joking aside, the feature gives you both a value type and documents the intent of function intentionally possibly not returning a value.

This will be C++ std::expected:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p032...

Returns a value (as in std::optional) than can be null. If so you will get an error explaining what happened.

Reply on news.ycombinator.com