(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)
Disjunction: is /foo/
the same object, or a new object, each time it’s evaluated in ES3?
According to ECMA-262 3rd edition, what should this code print?
function getRegEx() { return /regex/; } print("getRegEx() === getRegEx(): " + (getRegEx() === getRegEx()));
The answer depends upon this question: when a JavaScript regular expression literal is evaluated, does it create a new RegExp
object each time, or does it evaluate to the exact same RegExp
object each time it’s evaluated? Let’s look at a few examples and make a guess.
I sense a pattern
var tests = [ function getNull() { return null; }, function getNumber() { return 1; }, function getString() { return "a"; }, function getBoolean() { return false; }, function getObject() { return {}; }, function getArray() { return []; }, function getFunction() { return function f(){}; }, ]; for (var i = 0, sz = tests.length; i < sz; i++) { var t = tests[i]; print(t.name + "() === " + t.name + "(): " + (t() === t())); }
If you test that code, you’ll see that the first four results are true, and the rest are false, all per ECMA-262 3rd edition. (Okay, technically, and bizarrely, ES3 permitted either result for the function case, but no browser ever implemented a result of true; ES5 acknowledges reality and mandates that the result be false.) The first four functions return primitive values; the last three return objects. There’s only a single instance of any primitive value — or, alternately, you might say, equality doesn’t distinguish between different instances of the same primitive. Therefore it doesn’t really matter whether primitive literals evaluate to new instances or the same instance. On the other hand, objects compare equal only if they’re the same object. Since the object cases didn’t compare identically, they must be new objects each time. This makes sense: if this were not the case, what would happen in the following example?
function makePoint(x, y) { var pt = {}; pt.x = x; pt.y = y; return pt; } var pt1 = makePoint(1, 2); var pt2 = makePoint(3, 4);
It would be complete nonsense if the object literal above evaluated to the same object every time it were encountered; the next two lines would blow away the previous point, and we would have pt1.x ===3 && pt1.y === 4
.
Plausible assertion: regular expression literals evaluate to new objects when encountered?
Returning to the original question, then, what does ES3 say this code should print?
function getRegEx() { return /regex/; } print("getRegEx() === getRegEx(): " + (getRegEx() === getRegEx()));
A regular expression is an object. If you don’t want to get weird property-poisoning of the sort just suggested, regular expression literals must evaluate to different objects each time they’re encountered, right?
Alternative: ES3 says /foo/
is the same object every time
Wrong. According to ES3, there’s only a single object for each regular expression literal that’s returned each time the literal is encountered:
A regular expression literal is an input element that is converted to a RegExp object (section 15.10) when it is scanned. The object is created before evaluation of the containing program or function begins. Evaluation of the literal produces a reference to that object; it does not create a new object.
This was originally a dubious optimization in the standard to avoid the “costly” creation of a regular expression object every time a literal would be encountered. It’s perhaps a little surprising that the same object is returned each time, but does it make a difference in real programs not written to demonstrate the quirk? Often it doesn’t matter. As a simple example, if (/^\d+$/.test(str)) { /* ... */ }
executes identically either way, assuming RegExp.prototype.test
is unmodified. The RegExp
never escapes, and its use doesn’t depend on mutable state, so creating new objects each time doesn’t make a difference (other than negligibly, in speed).
Sometimes, however, the shared-object misoptimization does matter meaningfully: when a RegExp
with mutable state is used in ways that depend on that state. Most regular expressions don’t store any state, so if the same RegExp
object is used twice it’s no big deal. However, it can matter a lot for regular expressions specified with the global
flag:
var s = "abcddeeefffffgggggggghhhhhhhhhhhhh"; function next(s) { var r = /(.)\1*/g; r.exec(s); return r.lastIndex; } var r = []; for (var i =0; i < 8; i++) r.push(next(s)); print(r.join(", "));
Each time a regular expression with the global
flag is used, its lastIndex
property is updated with the index of the location in the matched string where matching should resume when the regular expression is next used. Thus, in this example we have mutable state, and if next
is called multiple times we have uses which will depend on that mutable state. Let’s see what happens in engines which implemented regular expression literals per ES3. If you download the Firefox 3.6 release candidate and test the above code in it (adjusting the implied print
to alert
), the printed result will be this:
1, 2, 3, 5, 8, 13, 21, 34
ES5: an escape to sanity
Is ES3’s behavior what you’d expect? No, it isn’t. In fact, ES3’s behavior, which Mozilla and SpiderMonkey implement, is the second-most duplicated bug filed against Mozilla’s JavaScript engine. SpiderMonkey and (strangely enough) v8 are the only notable JavaScript engines out there that implement ES3’s behavior. ES3’s behavior is rarely what web developers expect, and it doesn’t provide any real value, so ES5 is changing to the behavior you’d expect: evaluating a regular expression literal creates a new object every time.
Starting with Firefox 3.7, Firefox will implement what ES5 specifies. Download a Firefox nightly from nightly.mozilla.org and test it out as above (use the profile manager if you want to keep your current Firefox settings and install untouched). Instead of the Fibonacci sequence you’ll get this:
1, 1, 1, 1, 1, 1, 1, 1
The bottom line
Starting with Firefox 3.7, evaluating a regular expression literal like /foo/
will create a new RegExp
object, just as evaluating {}
or []
currently creates a new object or array. The optimization ES3 specified has resulted in clear developer confusion and was misguided and inconsistent with respect to other object literal syntax in JavaScript.
Again, as with my previous post, we doubt this change will affect many scripts (in this case, except for the better). The fact that few browsers implemented ES3’s semantics means that most sites have to cope with either choice of semantics, so the semantics in ES5, implemented by Mozilla for Firefox 3.7, are likely already handled. Still, it’s possible that this change might break some sites (particularly those which include browser-specific code), so we’re giving a heads-up as early as possible.
Your title confuses me a bit, don’t you mean either ‘ES3 incompatible’ or ‘ES5 compatible’?
Comment by Dorus — 15.01.10 @ 12:01
Oops, yes, retitled.
Comment by Jeff — 15.01.10 @ 13:53
So, the correct way to iterate over a global regexp is to save it in a variable first?
Comment by Neil — 16.01.10 @ 03:44
I’m not sure I understand the question. If you’re going to iterate through a string, you should make sure to use a new regular expression each time you do so. This suggests that global regular expressions probably shouldn’t be defined at top level outside of loops. However, if you do define it that way but don’t use the regular expression after you’re done iterating, you should be fine.
Comment by Jeff — 16.01.10 @ 12:00
I know Opera implemented this per ES3 but I don’t remember off the top of my head how long that implementation lasted.. Just like Mozilla, we have a number of bug reports against the ES3 behaviour.
Comment by Hallvord R. M. Steen — 25.01.10 @ 07:57
[…] nonintuitive behavior, but Firefox (and later Google Chrome) did, and as a result it became the second most duplicated JavaScript bug report for Mozilla. Fortunately, ES5 got rid of this rule, and now regex literals […]
Pingback by What the JavaScript RegExp API Got Wrong, and How to Fix It — 01.03.10 @ 00:43
Thanks so much for this incredibly useful information. I ran into the exact situation you described with a validation routine. It worked as expected in Internet Explorer, but not so in Firefox.
You saved me a lot of confusion over the strange behavior the code was exhibiting.
Comment by Wandering Dude — 21.05.10 @ 11:49
[…] didn't follow the spec on this unintuitive behavior, but Firefox did, and as a result it became the second most duplicated JavaScript bug report for Mozilla. Fortunately, ES5 got rid of this rule, and now regex literals […]
Pingback by JSSpy » What the javascript regexp api got wrong, & how to fix it — 02.09.12 @ 17:45