Supporting feature tests directly

Kyle Simpson getify at
Sun Mar 22 22:26:31 UTC 2015

> likely to be engine variances in the future

I hope you just mean like changes that ES7 might make to an ES6 feature. And I hope those aren't syntactic as much as semantic. :)

If there was a change on syntax, I would assert that should be considered a "new feature" with its own new test, even if it was just a variation on an existing one. Like `Symbol.arrowLiteral` and `Symbol.conciseArrow`, where the second test might check specifically places where the grammar for arrows was relaxed to allow omission of `( )` or whatever.

> knowing that the syntax is supported doesn't mean that ES6's semantics apply

That's true. But I think semantics are more a run-time concern, and thus should be checked with actually executed code (`Function(..)`, etc).

Off the top of my head, things which are statically verifiable, like duplicate param names, could be checked (if that's the kind of thing a parser even checks), but things like if we relax and allow implicit symbol coercion are much more clearly run-time errors.

> If that's the sole goal - detecting SyntaxErrors efficiently without using eval

Yep, that's it.

Consider it a first-pass quick feature test for syntax… if more extensive deeper run-time semantics checks are necessary, that would more be the realm of `Function(..)` or other similar (future) features. At least in those deeper-check cases, you wouldn't have to worry about catching `SyntaxError`s, since you could know in advance before trying the more performance-expensive tests.

More information about the es-discuss mailing list