> That doesn't mean you won't need a "not a valid object" for a type. This confuses two different concepts, and that confusion is precisely the problem with "n

> That doesn't mean you won't need a "not a valid object" for a type. This confuses two different concepts, and that confusion is precisely the problem with "null". Most types neither need, nor have, a "not a valid object" value. The "not a valid object" value is typically disjoint from the type. Null can't be used instead of some other type, as though it were that type. Instead, you have to perform a comparison to decide whether you're dealing with null, or a value of the expected type. The problem with null, in languages that have it, is the inability to statically prove that terms cannot be null. This means null is a pervasive possibility that almost always has to be checked for, which is an unnecessary source of bugs. Strictly speaking, you always have to check for null, except in those cases where you can prove (informally, since the compiler doesn't help with this) that you already did that. > That's why there all these Optional and Maybe constructions - you're still checking for it. The point is that option types allow you to choose whether you want to allow non-values at a particular term. If you don't - e.g. if a function returns a value not wrapped in an option type - then you're statically guaranteed to be able to use that value without having to check for null. The only place where you need option types are where you're explicitly allowing for an optional value. And in that case, the option type helps because it statically disallows you from treating the value as though it were an instance of the underlying type. So while it might seem like "you're still checking for it," there's an important difference in the context of that check - the compiler will give you an error if you try to use the value without unwrapping the option.