You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.
In my ideal world, it would be an early error to refer to a private field which is not lexically in scope: e.g. it would be an early error to write class C { m(){ #a; } } at the top of a module. However, class { m(){ #a; } #a; } should remain legal, so this might be difficult (because we don't know if a field is in scope until later).
But I think we could at least ban private field references which occur outside of any class body, which is something we know at the time that we see the reference. Depending on how this is done, this could also have the effect of preventing access to fields from within eval.
The text was updated successfully, but these errors were encountered:
PRs still accepted! I wrote out the ones in your TODOs, but I'm happy to see @bakkot filing bugs on ones that are still missing. @zenparsing , were there any more things on your mind for important early errors? I'd like to fix the remaining ones in the next couple weeks.
In my ideal world, it would be an early error to refer to a private field which is not lexically in scope: e.g. it would be an early error to write
class C { m(){ #a; } }
at the top of a module. However,class { m(){ #a; } #a; }
should remain legal, so this might be difficult (because we don't know if a field is in scope until later).But I think we could at least ban private field references which occur outside of any class body, which is something we know at the time that we see the reference. Depending on how this is done, this could also have the effect of preventing access to fields from within
eval
.The text was updated successfully, but these errors were encountered: