New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parse class heritage as strict mode code #9315
Parse class heritage as strict mode code #9315
Conversation
nicolo-ribaudo
commented
Jan 11, 2019
•
edited by loganfsmyth
edited by loganfsmyth
Q | A |
---|---|
Fixed Issues? | Fixes #8186 |
Patch: Bug Fix? | 👍 |
Major: Breaking Change? | |
Minor: New Feature? | |
Tests Added + Pass? | Yes |
Documentation PR Link | |
Any Dependency Changes? | |
License | MIT |
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/9754/ |
1 similar comment
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/9754/ |
@@ -994,8 +994,16 @@ export default class StatementParser extends ExpressionParser { | |||
this.next(); | |||
this.takeDecorators(node); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know if class decorators are also technically auto-strict? The spec currently says
All parts of a ClassDeclaration or a ClassExpression are strict mode code.
and I have no idea if that is something that is meant to include decorators, or if the decorators proposal will be changing that line to specifically call out the Body and Heritage.
I could see auto-strict decorators being annoying if support for decorating things other than classes were to be considered in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The decorators please doesn't say anything about it. @littledan wdyt about it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have opened tc39/proposal-decorators#204
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are not, because whether it’s a decorator or not is determined at invocation time, not at the time you write the function body.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What of you directly write the function inside the decorator?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I misunderstood the question :-) i believe without additional specification, it’s just like any other function - inherits strict from the lexical context or uses the pragma to turn it on.
I will merge this for now, if you are interested in the strictness of decorators you can watch tc39/proposal-decorators#204. |