Normative: Let all early errors be SyntaxErrors.

[rkirsling]

Resolves #691.

(This does not handle all concerns discussed in that thread, but it does serve as a solution for the OP.
See #691 (comment) onward for my own reasoning; in hindsight, I should've made a separate issue.)

[leobalter]

Nice, I'd love to see the outcome of this in the meeting. I'm somehow neutral do this change (on how it is concluded), and interested to hear more feedback from TC39.

[mathiasbynens]

Ross, could you please copy-paste the table from #691 (comment) to your top post here? Saves people a click :)

It’s interesting that these are ReferenceErrors in all engines except for SpiderMonkey, and so this proposal doesn’t really match reality. What’s the concrete benefit of this change?

[rkirsling]

@mathiasbynens My pleasure!

	early ReferenceError	early SyntaxError
UpdateExpression (0++, ++0)	V8, Ch	JSC, SM
AssignmentExpression (0 = 0, 0 += 0)	V8, Ch, SM	JSC

So the status is that JSC has yet to make these early errors at all implemented SyntaxError for both, while SM is refusing to implement an early ReferenceError for UpdateExpression to ensure that we have this conversation. 😁

Mainly, it's strange that out of 40 sections' worth of early errors in the spec, only two include early ReferenceError cases. In particular, [0] = [] and for (0 of []) {} are early SyntaxErrors. So we certainly can't say that the spec is consistent in its current state.

Now, one might question whether it's really worth going back on an earlier decision here, if early error types are mostly "cosmetic" anyway. But as @allenwb pointed out in #691 (comment), it's eval that makes this an observable concern. It would be one thing to have multiple error types that are exclusively "early", but as a user, it's problematic that I can't distinguish an early ReferenceError from a late one (short of matching on error message strings 😳).

---

Edit (5/16): Updated JSC status from late ReferenceError to early SyntaxError.

[allenwb]

Mainly, it's strange that out of 40 sections' worth of early errors in the spec, only two include early ReferenceError cases. In particular, [0] = [] and for (0 of []) {} are early SyntaxErrors. So we certainly can't say that the spec is consistent in its current state.

It's not strange, it's history.

1. Starting with ES1 these errors were specified to be runtime Reference Errors (in PutValue). But ES1 Clause 16 said that the spec. identifies the "last possible moment" where an error must be detected. Implementations are allowed to detect and report any error earlier including during parsing.

2. ES3 changed clause 16 to say that runtime errors should be reported when the construct is executed. But it goes on to says that PutValue Reference Errors (and a few others) may be treated "as a syntax error and therefore report it early". It also says that other than the listed special cases, implementations shall not report runtime errors early.

3. ES5 clause 16 says implementation must treat PutValue Reference Errors as early errors if an early determination can be made that the error will always occur.

4. ES6 introduced the isValidSimpleAssignment abstraction operation that determines whether a PutValue operations will always produce a ReferenceError and provides static semantic rules that produces an early ReferenceError for these cases when isValidSimpleAssignment return false. It also says that if an eval fails because of an early error that eval throws a SyntaxError exception to report the error.

So the specified error for PutValue has always been ReferenceError. And reporting of early detectable errors has evolved from may be reported as soon as possible to must be an early error. The specification has always been mute about how early errors are reported and whether or not "syntax error" means the same thing as "SyntaxError".

It doesn't matter when we're talking at the level of parse time error messages. It really only makes a difference when early errors are reflected back as actual exceptions via eval and ES6 said those should be SyntaxErrors.

[bakkot]

Thanks for the history, @allenwb. It stops a little early, though: #156, included in ES2016, changed the semantics for PeformEval from

If the parse fails or any early errors are detected, throw a SyntaxError exception

to

If the parse fails, throw a SyntaxError exception. If any early errors are detected, throw a SyntaxError or a ReferenceError exception, depending on the type of the error

Which means that it currently is the case that the type of the early error is in fact reflected back as in the actual exception thrown by eval.

---

As a small aside, it's not quite the case that the types of parse errors at the top level (i.e., not in eval) are unobservable in practice in the most common ECMAScript hosts, i.e. web browsers: compare the alert you get when opening

<!doctype html>
<html>
<head><title>demo</title>
<script>
addEventListener('error', e => { alert(e.error.name); });
</script>
<script>
0++;
</script>
</head>

in Firefox (SyntaxError) vs Chrome (ReferenceError).

(Github doesn't allow data: URIs in links, but you can open

data:text/html;charset=utf-8,%3C%21doctype%20html%3E%0D%0A%3Chtml%3E%0D%0A%3Chead%3E%3Ctitle%3Edemo%3C%2Ftitle%3E%0D%0A%3Cscript%3E%0D%0AaddEventListener%28%27error%27%2C%20e%20%3D%3E%20%7B%20alert%28e.error.name%29%3B%20%7D%29%3B%0D%0A%3C%2Fscript%3E%0D%0A%3Cscript%3E%0D%0A0%2B%2B%3B%0D%0A%3C%2Fscript%3E%0D%0A%3C%2Fhead%3E

if you want.)

But that's neither here nor there.

[allenwb]

Which means that it currently is the case that the type of the early error is in fact reflected back as in the actual exception thrown by eval.

Possibly an ill-advised changed. The intent in the ES6 text was that a caller of eval should only have to check for SyntaxError in their catch to dispatch on the early errors. Not fool proof because of a few unfortunate legacy runtime SyntaxError, but pretty close. Not turning early ReferenceErrors into SyntaxError makes it worse in that respect.

[bakkot]

I agree. This patch resolves that difficulty with a slightly larger-than-necessary hammer.

[rkirsling]

This is now implemented in JSC (as they needed to be turned into early errors regardless). 😄
https://trac.webkit.org/r245406

[rkirsling]

This reached consensus today at the Berlin meeting. 🎉

Tests
tc39/test262#2147

Implementations

• JSC: WebKit/WebKit@facf59d (shipping in STP 83)
• SM: mozilla/gecko-dev@3e9d056 (scheduled for FF 69)
• V8: v8/v8@7fc00d8 (scheduled for Chrome 77)

[leobalter]

tests landed. Edit: sorry, just noticed the label change. Thanks @ljharb

[rkirsling]

(Resolved conflict.)

[rkirsling]

FWIW, this now has three landed implementations. 🎊