Discussion on: You don't need null

It seems that you asking this question proves the point.

My point was that you shouldn't assume the output of a function. In your previous comment you basically said that you "expect" something to return null. Based on your same logic in this new comment: "You have no idea what I (or other clients of your code) are going to do", so why is bad for me to assume you'll know that you shouldn't do matches === null, but is good for you to assume that the function will return null instead of actually checking the return type of the thing you're using?

And when/if you change that, you introduce the potential for bugs, as previously pointed out.

But that's the thing, if you use a function assuming it will return either null or undefined, why is it on me as the dev and not on you as the consumer of that function? I already said this, but the other way around your same argument applies, if you create a function that I expect will return undefined, and instead you decide that it will return null, then it's my problem that I was expecting your function to return something I wanted it to return, instead of checking the typing or using something like ??.

And I still don't see where the distinction between null and undefined is valuable here. With the same example of the util, if someone does a wrapper of something that generally returns undefined, and they make it return null, it could cause confusion as well.

I am not sure but I'll give the benefit of the doubt here and assume that you are not willfully missing the point.

Trust me, I'm giving you the same benefit. I added sources to the article for y'all to explore, because my personal experience of not using null in personal projects and at work, and not missing it at all, and explaining that the "distinction" between intentionally missing and unintentionally missing value is pointless because they are both missing and need to be dealt with the same way. Maybe checking some other sources besides my article adds some light to the subject, but if null is so necessary, how is it that Angular is considering dropping null, TypeScript doesn't use null in its source, and folks like Douglas Crockford, with years of experience in JS, don't use null at all and just use undefined instead?

As @darkwiiplayer pointed out several times already, that "need" for multiple nullish values is trivial, having 1, 2 or 10 different nullish values with differences you define with conventions, doesn't take back the fact that they are all still just nullish.

Every time I ask: Why do you need to do that distinction?

The answer is pretty much "because null exist in JavaScript for that", but that doesn't actually answer the question. There are several things that exist in JS to be used for something, and we realized that there are better ways to do that same thing and not use that feature (eval and with are the two that I mention constantly).

We might never agree on this, but the questions I leave to you are:

Do you actually tried to code without null at any point? Do you ever worked with a library/framework or codebase without null and missed having it? Because I sure did tried doing it "your way" in the past, and once I did the "transition" I never went back.