[cubefox]

I know this is not the point of the article, but I find the anecdote in the beginning about null pointer errors somewhat ironic. Haskell's solution to null pointers are option types (`Maybe x` in Haskell), but these are known to be suboptimal.

In languages with option types, if you want to weaken the type requirement for a function parameter, or strengthen the guarantee for a return type, you have to change the code at every call site. E.g, if you have a function which you can improve by changing

- a parameter Foo to Option<Foo> or

- a return value Option<Bar> to Bar

you would have to change the code at all call sites. Which could be anything between annoying and practically impossible.

In languages that solve null pointer errors instead with untagged union types (like TypeScript or Scala 3), this problem doesn't occur. So you can change

- a parameter Foo to Foo | Null or

- a return value Bar | Null to Bar

and all call sites of the function can remain unchanged, since the type system knows that weakening the type requirement for a parameter, or strengthening the promise for a return type, is a safe change than can't cause a type error.

So yes, option types do avoid null pointer exceptions, but they solve the issue in a very suboptimal way.

[qsera]

>you would have to change the code at all call sites.

Actually I think you can just change concrete argument `Foo` to type constraint in Haskell as well using a type class. So the function would be something like `foo :: ToMaybeFoo a => a -> .. ->`. And you would implment `ToMaybeFoo` instance for `Foo` and `Maybe Foo`.

Agree that this is more involved than typescript, but you get to keep `null` away from your code...

[kqr]

This is a neat idea, but it does require that you know up front the largest union that could ever be supported in that argument, so that you have the ability to narrow it down later. Worse, it in the limit it requires a combinatorial explosion of type classes, with one for each possible union! The `ToXYZorW` classes form a powerset over the available types.

[cap11235]

See fundeps.

[cubefox]

Admittedly I don't really understand your construction. But this solution, if it works, doesn't look practical enough that it could be routinely used in practice like Foo|Null could be. By the way, some languages even shorten "Foo|Null" to "Foo?" as syntax sugar.

> but you get to keep `null` away from your code...

I don't think this would be desirable once we have eliminated null pointer exceptions with untagged unions.

[qsera]

>Admittedly I don't really understand your construction.

It is quite simple. Instead of accepting a concrete type `Foo`, the function is changed to accept types that can be converted to `Option<Foo>`. Since both `Foo` and `Option<Foo>` can be converted to `Option<Foo>`, the existing call sites that passes `Foo` would not require changing.

https://play.haskell.org/saved/g4idq2zv

[wazHFsRy]

Mostly though if you do anything with the returned value at the call site you need to change that code anyways? If it is not just passing it on, and even then you might need to adapt its signatures. E.g. if you change from String | Null to String you remove the null handling. If you add Null you need to add Null handling?

[cubefox]

No that's not right.

If you were calling a function which might return null (String | Null), you will already have null handling at the call site, but if you now change that function such that it never returns null (String), you still have the (now unnecessary) null handling, but this doesn't hurt and you don't have to change anything at the call site.

Likewise, if you were passing a String to a function that doesn't accept null (String), the call site already made sure that the parameter isn't null, and if you change the function so that it does now accept null (String | Null), again nothing needs to be changed at the call site.

[django77]

I agree that this can be nice when done right (Clojure), but null is a high price to pay for this convenience.

I must admit I’ve never had this problem in application development. In fact, I do want to change my callers because strengthening the contract is an opportunity to simplify the callsites - they no longer have to handle the optionality. The change might carry some semantic meaning too, why are you getting x instead of Maybe x all of the sudden? Are there some other things you should reconsider in the callers? I can see how it could be useful in library development, but there are also patterns to account for this that are idiomatic to Haskell.

[cubefox]

> I agree that this can be nice when done right (Clojure),

I don't think Clojure has untagged union types like TypeScript or Scala.

> but null is a high price to pay for this convenience.

Why would it be? Untagged unions prevent null pointer errors just as much as option types do, only they don't have the discussed disadvantages of option types.

[django77]

I was thinking about a general experience of working with null/nil. Clojure has nil punning which makes sense in the context of the language (lisp variant) and can be nice to work with.

The null is a high price to pay because eventually someone will make some type assertion somewhere in the TS codebase that will end up biting you. Sure, you can be diligent, but will every contributor during the lifetime of a project be?

Not sure about Scala, but I did see NullPointerException every so often, and what is the practical advice to handle them in Scala? It’s to use Option[T]

[cubefox]

> The null is a high price to pay because eventually someone will make some type assertion somewhere in the TS codebase that will end up biting you. Sure, you can be diligent, but will every contributor during the lifetime of a project be?

Type assertions and untagged union types are entirely independent. Supporting untagged unions doesn't imply supporting type assertions, and not supporting untagged unions doesn't imply not supporting type assertions.

> Not sure about Scala, but I did see NullPointerException every so often, and what is the practical advice to handle them in Scala? It’s to use Option[T]

Scala only supports untagged unions since version 3, so that's probably the reason why they are not used everywhere yet.

[Munksgaard]

> Why would it be?

That's literally what they explain in the rest of the comment.

[cubefox]

No, they don't reference any "high price to pay", only that they personally didn't need the advantages of untagged union types so far, and that Haskell (allegedly) has patterns that would play a similar role for libraries.

[matt-noonan]

This is really a non-issue in practice. In the olden days, you’d just make the change and then spend a pleasant hour or two fixing the callsites by responding to compiler errors in a pretty low-thought, mechanistic way. Nowadays you can outsource that part to a coding agent and get on with your life.

In any case, the fact that the compiler knows what code needs to be updated is a real superpower.

[cubefox]

Well, it's still a suboptimal solution. Moreover, if you are modifying any library functions, there is a high probability that you can't change the call sites at all because you simply don't have access to them.