> 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. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
