Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

This is somewhat tangential, but in my opinion implementing Optionals as a "normal" wrapper type, as is done in Java, doesn't really help that much, and can in fact actively hurt, because (a) there is nothing that prevents an Optional variable from actually being null (I've seen a method with an Optional return type that returned null in some cases - obviously a horrible decision, but not prevented by the compiler nonetheless), (b) you don't get compiler support that knows, for example, that if you preface an empty check on the variable that it's then safe to get the value and (c) it makes code super-verbose and hurts readability.

You really need first class support for optionals, a la TypeScript and Kotlin, to get a benefit IMO.

View on HN

> nothing that prevents an Optional variable from actually being null

That's why you're supposed to use Optional<Optional<X>>. ;-)

> This is somewhat tangential, but in my opinion implementing Optionals as a "normal" wrapper type, as is done in Java, doesn't really help that much

The great thing about Rust is that `Option` is a normal, generic type. You could very easily implement your own equivalent type.

Not quite. The compiler does have the knowledge that it can use \0 for representing None in Option<Pointer> types. I'm not sure it can infer that for home-grown Option enums.

So it can optimize the memory overhead of Option<> away completely.

That is called “niche optimization” and the compiler will in fact still do it for a hand-rolled Option type.

Although, Rust only knows about certain obvious niches. It can reason that it can fit None in the same space as NonZeroU64 or a reference &T but it doesn't see how to do this with a hypothetical EvenU64 as I understand it because that "niche" is in the wrong place.

For anyone not sure, here is the proof.

https://godbolt.org/z/4zhWM9hTP

My experience is they helped a lot. a) basically never happened (I have a vague recollection of catching one in code review, but usually my reviews would instead be "instead of returning null here, use Optional please" or figuring out a way to avoid nulls entirely (e.g. empty list when returning collections)) b) I think both Eclipse and IntelliJ will issue a warning if you perform an Optional.get() without an isPresent() check c) it seems less verbose and more readable than null checks, especially if you have a map chain/are using Streams. It could be even nicer, like what Kotlin has, but it's an improvement.

Java Optionals are useful in Streams.

I've found I agree with the principle that Optionals only make sense for return values (and if the method returns null, that should be treated as a bug).

I've seen Optionals used for member variables, and they might as well just be null. (And are highlighted as such by IDEs like IntelliJ).

It works very well in ML-like languages. The problem is when you have a language where everything can be null. TS and Kotlin need first class support for optional because the underlying language has first class support for null.

- if you don’t use null this isn’t an issue

- it’s verbose because handling optional values safely is complex

> if you don’t use null this isn’t an issue

I mean, no shit. But the problem is that tons of existing Java APIs do use nulls, so you can't just pretend they don't exist, and importantly a major point of the optional construct is to get compile-time guarantees, and the Optional class doesn't give you that.

> it’s verbose because handling optional values safely is complex

No, it's not. Kotlin has optionals built into the language, and it's safer and much less verbose.

Nit: Kotlin doesn't exactly have optionals, it has essentially a type modifier (?) that represents a "nullable" type, i.e. the sum of a type T and the value 'null'. This is indeed safer and terser, therefore strictly more powerful than Java's Optional type, but it begs a question: Why not allow users to create similar higher-kinded types instead of baking this one very specific type kind into the compiler?

Their recent decision to axe typeclasses in favor of multiple function receivers, which solves a small subset of problems that HKTs do in Scala and Haskell, make me look for greener pastures whenever I need them.

How is "handling optional values safely" complex? Do you have any examples of that?

First class support for nullable is more basic and needed.

Java On its own it doesn’t support this however there are ways of enforcing this in a Java codebase. Eg: Errorprone and NullAway comes to mind here.

Reply on news.ycombinator.com