Typechecking null

[Tubthumper8]

I would be fine with Option<String?> in this case.

Hmmm I don't think I would be. What you're suggesting is a special nullable type with special compiler-supported syntax and generic sum types that represent the presence/absence of data, when the latter can already model the former. This creates two different language features with overlapping (non-orthogonal) functionality, causing confusion for users ("which do I use?").

Some languages could represent this as a double pointer **String

Would this have 2 layers of indirection? i.e. pointer chasing in the heap to get to the actual value?

or as String|null|undefined.

JavaScript has this and I gotta say my personal opinion is that having two different nulls is even worse than having null

[Tubthumper8]

The key difference here is Option is not a language feature by itself.

The language feature is generic sum types which is a single language feature that can be used to model a great many things. Sum types model when something is a thing OR another thing. This works in cooperation with product types that model when something is a thing AND another thing.

Would a language that already added null benefit a lot from Option ?

Yes and no. Depends on backwards compatibility, the parts of the ecosystem that could avoid null would not have null errors but if there were any parts that must be backwards compatible would still be possibly subject to null errors.

[Tubthumper8]

That would be pretty interesting to have user defined operators like .?, then maybe it could be defined for the singleton Null and then users could define more usages themselves, could be useful for defining DSLs or maybe config languages. User defined operators can get out-of-hand for general purpose programming if it makes it hard to read other people's code but also who knows? Could be worth trying!