proposal-class-fields
proposal-class-fields copied to clipboard
Clarify that private fields can be accessed from within eval
@caitp ran into some ambiguity in the way the specification is worded here. I'm not sure whether we need a fix per se (e.g., #40), or whether we just need to add more notes to make it more clear.
I don’t think it’s worded ambiguously, I had just assumed that the algorithm was consistent between the 2 versions of eval where it comes up, and only really looked carefully at one instance (CreateDynamicFunction).
I still maintain that exposing private fields to eval() is a bad idea.
We discussed whether private fields should be available in eval in the November 2016 TC39 meeting. Unfortunately, the notes are rather sparse; my recollection is that, after I tried to argue that private fields should not be available in eval, @ajklein made the argument that it would be surprising if we didn't permit them, given that other new features like let-scoped variables are available in eval.
I would argue that you should be able to access private fields from eval for the same reason that you can access them from arrow functions in methods.
You cannot call an arrow function with a different this value, and an eval has access to the same this context as an arrow function.
I would argue that you should be able to access private fields from eval for the same reason that you can access them from arrow functions in methods.
that might be something you'd want to explicitly allow with a CSP relaxer option, rather than a default --- even if you explicitly allow evaluating strings, you might not want them to access private stuff.
I don't feel strongly about this, just throwing that out there
if you explicitly allow evaluating strings, you might not want them to access private stuff.
Developers have been taught to treat eval as if it were run with the same privileges as the caller. I think it should stay consistent with current standards, and eval should only gain access to private fields when it would also gain access to local variables.
To clarify, the current specification does allow private fields and methods to be accessed from inside eval. This issue tracks making the specification editorially more clear on that point.