12.01.10

More ES5 backwards-incompatible changes: the global properties undefined, NaN, and Infinity are now immutable

(preemptive clarification: coming in Firefox 3.7 and not Firefox 3.6, which is to say, a good half year away from now rather than Real Soon Now)

JavaScript and the undefined, Infinity, and NaN “keywords”

Consider the following JavaScript program: what do you think it does?

print("undefined before: " + undefined);
undefined = 17;
print("undefined after:  " + undefined);

The above program will print this output:

undefined before: undefined
undefined after:  17

Surely you can’t be serious!

A sane person might think that this program isn’t even a program. Doesn’t undefined always refer to the primitive value undefined? After all, this “program” isn’t one, nor would be the same one for true or false, mutatis mutandis:

print("null before: " + null);
null = 17; // !!! NullLiteral is not a LeftHandSideExpression
print("null after:  " + null);

I am serious…and don’t call me Shirley

Curiously, the program that assigns to undefined is a valid JavaScript program, but programs that assign to null, true, and false are not. Why not? The latter are all keywords with intrinsic meaning within the language; undefined, on the other hand, is just a normal property of the global object. According to ECMA-262 3rd edition, if you assign a different value to undefined, that different value becomes the new value of undefined.

This is a clear botch in ES3. undefined should have been a keyword in JavaScript from the beginning; similarly, the global properties Infinity and NaN probably should have been keywords as well (or perhaps the properties should not have existed, given that Math.Infinity and Math.NaN exist and are immutable). ECMA-262 5th edition doesn’t quite go so far as to change these three properties into keywords due to backwards compatibility concerns (making that change would be guaranteed to break any programs that even tried to assign to those names, regardless whether the program relied on that assignment for correctness). Instead, it changes these properties to be read-only, in the same way that the various numeric properties on the Math object are read-only. Assigning to these properties in ES5 won’t do anything (unless you opt into strict mode, in which case a TypeError exception will be thrown after we fix bug 537873), but at least it won’t definitely and completely break existing programs that relied on this.

We’ve made this change in SpiderMonkey, and it is now in trunk builds of Firefox, slated for the eventual Firefox 3.7 release. Download a nightly build from nightly.mozilla.org and test out the change for yourself (use the profile manager if you want to keep your current Firefox settings and install untouched). This change should have no effect on the vast, vast majority of web developers who don’t try to change the values of these properties; as for the [civility and my religion require I redact this description] developers who did change the value of the global undefined, NaN, or Infinity properties, well…you had it coming.

The bottom line

The global properties undefined, Infinity, and NaN will be read-only and immutable in Firefox 3.7. Assigning to these properties will do nothing (except in strict mode where a TypeError exception will be thrown once we fix a bug) rather than changing their values. This shouldn’t break the vast, vast, vast majority of scripts out there — but there’s no way to guarantee it will break no one, so we think it’s worth announcing this backwards-incompatible change as proactively as possible.

7 Comments »

  1. What will:

    function foo() {
      var undefined = 17;
      print("value: " + undefined);
    };
    foo();
    

    do?

    Comment by voracity — 12.01.10 @ 20:45

  2. The only changes made were to the properties of the global object. This example creates a local variable whose name means that it happens to shadow the name of a global property. That’s perfectly acceptable as far as both ES3 and ES5 go, so your example should print “value: 17”.

    None of that, however, changes the fact that you shouldn’t be doing this! This is incredibly, incredibly poor style likely to confuse anyone who reads your code. (This is another thing that making these names keywords would have “fixed” by breaking the code, incidentally.)

    Comment by Jeff — 12.01.10 @ 20:55

  3. Cruel interview question: blackbox debugging of a subtle bug caused by |undefined = “undefined”|.

    Comment by Justin Dolske — 12.01.10 @ 23:04

  4. Sure, that’s fine. ‘undefined’ is such a primitive and crucial concept, that there’s no justification I can think of (or even imagine) for overloading it. (At least, not in this context.)

    Comment by voracity — 12.01.10 @ 23:11

  5. Hopefully a warning will be generated when Firefox does nothing in non-strict mode?

    Comment by Benjamin Stover — 15.01.10 @ 10:39

  6. […] as with my previous post, we doubt this change will affect many scripts (in this case, except for the better). The fact that […]

    Pingback by Where’s Walden? » More ES5 backwards-incompatible changes: regular expressions now evaluate to a new object, not the same object, each time they’re encountered — 15.01.10 @ 13:50

  7. If you have warnings enabled via javascript.options.strict, then yes, you’ll get a warning.

    Comment by Jeff — 15.01.10 @ 13:52

RSS feed for comments on this post. TrackBack URI

Leave a comment

HTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>