The history of “typeof null” (2013) (opens in new tab)

I don't know much about this, but I thought this was a solved problem in the JS ecosystem.

You write Typescript or CoffeeScript or Clojurescript or ES6 or in this case "JS edition2023". You have a preprocessing step that compiles this into code that works on everyone's browser. Your new language has the features and quirks you want, without having to solve the problem of deploying a new runtime to a billion older machines.

If you want a version of typeof without this quirk it is trivially easy to write a typeof2023() function with the desired behavior. And it would be fully backwards compatible with existing code and existing browsers.

No need to fork the language for this!

"use strict" was for fixing some fundamental mistakes which couldn't be fixed in a backwards-compatible way.

In JavaScript this is best done using linters to warn against deprecated features.

“Use strict” was necessary because it changed runtime semantics in a non-backwards compatible way. But browser vendors does not like to support multiple incompatible modes, it is much preferrable to introduce improvents in a backwards-compatible manner.

I've thought of something like that before for js. For this precise case, I guess the directive could forbid the use of typeof, or its use on null (and make it a runtime error). And your code ought to not accept values returned by typeof from foreign code, or to be careful with the "object" case.

I don't think it can be a complete solution for making typeof return "null" for null for two reasons.

1) If you call f(typeof v) where f is defined in a module written in a different version, you are screwed. Contrived but within spec and we all know https://xkcd.com/1172/ (if you didn't, now you do).

2) Moreover, old engines will ignore your directive and behave differently (return "object" instead of "null"), so now your code is incorrect depending on what engine runs it.

In the end, it could as well be a linter rule that forces you to test v === null before calling typeof v and I think it would be the best option. If you care about this kind of stuff, you are probably already using a linter. The same kind of tool that complains about "==", which sets the same kind of traps, and you don't need to wait for something wrong to happen during execution, it's already warned statically before even running the code.

That's basically what "use strict" is, isn't it?

If my programming language changed something so fundamental, I would lose all trust in it even if I don't rely on this particular quirk.

PL design is complicated and you pretty much have to keep this kind of quirks forever or at least for a very long time if you want to avoid a painful transition, which can lead to the old language version hanging out forever in the wild because a lot of code is already written in it. You can deprecate the features the quirks affect and introduce new ones to replace them that do not have the quirks, but now you need to support both ways for a very long time until the ecosystem is ready, which may never happen.

there's nothing wrong with:

    switch (typeof v) {
       ...
       case ...:
          ...
          break;
       case "undefined":
          // handle undefined;
          break;
       case "object":
          if (!v) {
              // handle null;
          } else if (v instanceof 'Array') {
             // handle array;
          } else if (...) {
              ...
          } else {
             // handle anything else
          }
          break;
    }

that's within spec and an alternative could be more verbose / more difficult to navigate (it's a matter of taste). If you need to handle undefined and null differently, you need to test for it and typeof === "object" is one way. I would probably do it differently, but I can see someone thinking differently and we can't blame them.

"doesn't really affect me" until you find out one of the libraries you use is affected by it and you find yourself scrambling to fix it in production as new users update their browsers

It’s waaaaaaay more common than you think. As a simple example, with React, the presence of a component with null state (which I imagine to be an extremely common combination) would break your entire site.

> This is a bug and one that unfortunately can’t be fixed, because it would break existing code.

Supposedly "because it would break existing code".

Existing code might rely on this behavior, so if it changed some sites will stop working. Even if those sites were updated to the new behavior, browsers are not updated at the same time, so either way there would be a lot of breakage.

And some sites will never be updated because they are not actively maintained.

You drastically underestimate how much code depends on typeof null being "object". It’s extremely common in generic/library code. If you changed it to produce, say, "null", vast numbers of websites would completely break. As a simple example, a brief glance at the React and ReactDOM source code, inspecting the first few /typeof.*'object'/ matches, shows that in React, component.setState(null), and in ReactDOM, rendering class-based components with null state (which I’m guessing will be pretty much normal in existing code bases, even if it’s an older pattern now; but I haven’t ever used React seriously), would both throw an exception.

"The difference between a bug and a feature is longevity."

  -said by someone last millennium