The history of “typeof null” (2013) | Hacker News Reader

The history of “typeof null” (2013)

2ality.com

57 pointsabdnafees32 comments

I could like to have a kind of rust edition for JavaScript.

You could opt in to an edition by adding a JavaScript directive at the start of the file — like the "use strict" directive. e.g.

  ```js
  "use edition2023"
  ```

This could enable to remove obsolete features and improve strictness.

EDIT: I forgot the "use" before "strict".

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

Yep. We could then disable more feature and change some historical errors like "use strict" did.

I think it is a bit different, because with "use strict" we have already some rules and the typeof null is object there and now is too late to change that. The same for any other feature we don't want to have in a language.

Maybe it was a mistake to introduce "use strict" without any other identifier, we need "use strict" with a version to be able to deprecate things and eventually remove from JS. Then JS engine could read it in the beginning of the file and know which version of js it is. Because in current JS we can only add new features without removing them. I am sure it is very complicated problem since we don't want to break the internet and browsers still have to work with old websites.

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.

(1) Yes this makes interoperability hard. However, `typeof` is generally used to test the type of value. It is unlikely to pass its value to a function

If you use a function declared in a module with a distinct edition, you have to comply to its contract. And its contract certainly state that "null" is not a valid value to pass through.

Moreover, a type checker or linter could error/warn about this.

(2) You are right.

Another solution might be to introduce a new keyword:

  ```js
  use "edition2023"
  ```

Old browser could thus crash. In the same way that they did for ESM.

  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.

Yes. However, this does not allow performing more advanced optimizations. Bundlers, Transpilerss minifiers, and compilers must handle all this complexity making some optimizations unsafe or even impossible.

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.

A lot of people are still writing raw JS code, including me, because the tooling around this is way more lightweight and straightforward, or because of over things.

But yeah, as a preprocessing step, I'd argue a linter rule would be one of the best way to handle such a quirk if you are using bare JS (or TypeScript, which inherits this quirk, by the way)

What I propose is introducing breaking changes via editions.

For instance, we could freeze class prototypes making impossible to dynamically replace a method or adding a method to it.

This what "use strict" did by forbidding `with` statements for example.

You never break user space.

Only a Sith deals in absolutes. Presumably that is why proposed mechanism requires the user to explicitly opt-in, just like with `"use strict";`.

Browsers still have to support the older editions for backwards compatibility, so each new edition increase complexity.

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.

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.

I don't know that I buy the would break existing code - sure the language would change but do we actually have stats of uses where we can see people did.. what would they have done?

if (typeof varname === "object" && !varname) { loggingNull("varname"); }

it seems far fetched and maybe those people's code should break.

I guess it doesn't really affect me though.

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

I find, via experiences on HN, that language is a vague and irritating source of misunderstandings, but I thought it was clear that doesn't really affect me was because I was not going to use typeof in this way ever, thus I did not really care if it got 'fixed' or not.

The point is you don't have to.

If you rely on any frameworks or libraries whatsoever, you can't assume they aren't using null in this way and would break if the language spec changed. The only common ground you and those developers have is the language specification's rules.

(If you actually do roll all your JS by hand in house, congratulations and I'm impressed, but (a) that's a minority position in any house that has to do professional JavaScript and (b) oh wow you're reinventing a lot of wheels).

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.

Why even? Why don't they fix it?

Supposedly "because it would break existing code".

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

https://www.hyrumslaw.com/

Linus Torvalds has long had an ironclad rule, "don't break userspace" which sounds like the same thing

from the hyrum's law link:

With a sufficient number of users of an API,

it does not matter what you promise in the contract:

all observable behaviors of your system

will be depended on by somebody.

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

  -said by someone last millennium

that's wrong, but it's been around so long I guess we have to accept it.

After asking the question, I looked for an answer and found the is-object npm package. It utilizes a null check to make sure a variable is an object. This utility has 6.6 million weekly downloads. The logic in the isObject function will break because the second condition would then be invalidated. Resulting in a bad day for 6.6 million projects. It took me a while to digest the magnitude. Maybe because I just started as an SWE.

If a language change were to update `typeof null` to return `"null"` isObject would not break, the second condition would only be unnecessary.

However, other code which may make assertions on null values after checking the value is an object would break.

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.

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.

Reply on news.ycombinator.com