What about directives?

[Yoric]

I haven't attempted to benchmark that, but in the current text source world, when parsing a function, the parser must:

1. start parsing with the current directives;
2. if the first child is a string, check the string;
3. if that string is "use strict", restart from 1 with different options.

That seems awkward. Maybe there is a better way to handle this in the binary world. Or maybe "use strict" doesn't really impact parsing all that much in the binary world, to be checked.

[littledan]

This is a source of complexity in V8's parser as well (except we track the potential errors all the time, to avoid backtracking ever). Could the AST pre-parse "use strict" and instead set a bit on the function and not represent the string directly anymore?

[syg]

@littledan Sounds like a good idea to me!

[ljharb]

(the string should still show up in the AST tho, even if there's a precomputed bit, no?)

[syg]

@ljharb The conservative option is as you say: to treat the presence of directives as an annotation, like the proposed solution for storing scope info. That is, the extra bit will be validated. If the bit for strict mode is set and no "use strict" shows up in the AST, an error is thrown.

AIUI @littledan is proposing a slightly more radical approach of treating the bit as the source of truth. I am fine with this personally given that directives already feel extra-linguistic, though it does deviate from the guiding principle of "encode as little extra semantic info as possible, just properties of the AST".

[Yoric]

On a technical note, I'm not sure that a single bit is the most future-proof manner of handling this. After all, I seem to remember that at least V8 and SpiderMonkey have experimented with additional directives.

So I'd be tempted to add a property

   directive: string | null

to both Function and Program (our AST root).

[Yoric]

Ah, I realize that the Babel AST already specifies a field

   directives: [Directive]

where Directive is basically a string literal. So, since we're following Babel for the moment, let's use it as is.

[fabiosantoscode]

Forcing strict mode and foregoing this discussion for now would also be a great thing. Whatever smashes the with statement.