Option Types vs Nulls
This cluster debates the superiority of explicit Option/Optional/Maybe types over traditional null pointers or nullable types in languages like Rust, Kotlin, Swift, and Haskell, emphasizing type safety, compile-time checks, and handling of absent values.
Activity Over Time
Top Contributors
Keywords
Sample Comments
Is there something that you can express with Option that you cannot express with a nullable type?
Not entirely true - e.g. Kotlin has null safety built into its type system, and I find it much nicer than the option/optional approaches used in various other languages.https://kotlinlang.org/docs/null-safety.html
Consider the following: some languages don't have null. When you need nullable what you really want is an Option/Maybe type. No null pointer exceptions, ever! It just won't compile until you fix the bug.
Rust has Option which you opt-into for cases like the one you describe.What's special is that it's not like Go/Java/JS/etc where *every* pointer/reference can be null, so you have to constantly be on guard for it.If I give you a Thing in Rust, you know it's a Thing and can use it as a Thing. If I give you an Option then you know that it's either a Some or None.If I give you a Thing in Go/Java/etc well, it could b nil. Java h
You don't need option types for the compiler to enforce safety around nulls. Its possible to model null as its own type in the type system to enforce safety.
I dont think this is true for the nullability type... Which are in essence compile time optionals... Without the overhead.
Get rid of retched compulsory nullability and offer optionally optional types. Could be via ADT style Maybe a = Just a | Nothing, or just a language feature eg Mytype vs Mytype?
It's not so much Optional that deals with the bug. It's the fact that you can't just use a value that could possibly be null in a way that would break at runtime if it is null - the type system won't allow you, forcing an explicit check. Different languages do this in different ways - e.g. in C# and TypeScript you still have null, but references are designated as nullable or non-nullable - and an explicit comparison to null changes the type of the corresponding variable to in
people should really try non-nullable types in typescript and kotlin, in addition to smart-casting. Then they would realize optionals are niche and cumbersome.
This comment is misleading. They may appear to be the same but they are not because in certain languages (like Rust) you are forced to handle the `Option` case when a value is `None` which guides a programmer's thinking in the direction of what to do in that situation.Without these higher level types runtime null pointer exceptions are very common, using `Option` or `Maybe` creates a situation where these sorts of errors are a lot less likely.