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

Inconsistencies in semantics of default module exports. #586

Closed
GeorgNeis opened this Issue Jun 2, 2016 · 3 comments

Comments

Projects
None yet
2 participants
@GeorgNeis
Contributor

GeorgNeis commented Jun 2, 2016

In 15.2.3.11 (Runtime Semantics: Evaluation), the evaluation of default exports
sets the exported object's "name" property to "default" in some cases. Unless I'm
misreading something, this is done in an inconsistent way.

This will set the class's .name to "default":
export default class {} // ClassDeclaration
This won't:
export default (class {}); // AssignmentExpression

For functions, the situtation seems reversed:

This will set the function's .name to "default":
export default (function() {}); // AssignmentExpression

This won't:
export default function() {} // HoistableDeclaration

Is this intended?

@allenwb

This comment has been minimized.

Show comment
Hide comment
@allenwb

allenwb Jun 2, 2016

Member

This won't:

export default (class {}); // AssignmentExpression

It will. This form is handled by the ExportDeclaration : export default AssignmentExpression ; algorithm in 15.2.3.11. Because IsAnonymousFunctionDefinition will return true for an AssignmentExression that is an anonymous class declaration.

This won't:


This looks like a spec. bug to me. The HoistableDeclaration case looks like it should have a step similar to step 4 of the ClassDelaration case of 15.2.3.11.

I can't recall any reason why I would have intentionally left it out for the HoistableDeclaration case.

Member

allenwb commented Jun 2, 2016

This won't:

export default (class {}); // AssignmentExpression

It will. This form is handled by the ExportDeclaration : export default AssignmentExpression ; algorithm in 15.2.3.11. Because IsAnonymousFunctionDefinition will return true for an AssignmentExression that is an anonymous class declaration.

This won't:


This looks like a spec. bug to me. The HoistableDeclaration case looks like it should have a step similar to step 4 of the ClassDelaration case of 15.2.3.11.

I can't recall any reason why I would have intentionally left it out for the HoistableDeclaration case.

@GeorgNeis

This comment has been minimized.

Show comment
Hide comment
@GeorgNeis

GeorgNeis Jun 6, 2016

Contributor

Thanks for pointing out my misunderstanding regarding the first part. Regarding the second part, maybe I'm wrong as well: I just found InstantiateFunctionObject, which is called in 15.2.1.16.4 (ModuleDeclarationInstantiation) and sets the "name" property to "default".

Contributor

GeorgNeis commented Jun 6, 2016

Thanks for pointing out my misunderstanding regarding the first part. Regarding the second part, maybe I'm wrong as well: I just found InstantiateFunctionObject, which is called in 15.2.1.16.4 (ModuleDeclarationInstantiation) and sets the "name" property to "default".

@GeorgNeis

This comment has been minimized.

Show comment
Hide comment
@GeorgNeis

GeorgNeis Jun 13, 2016

Contributor

I guess this can be closed. I no longer think there is a bug.

Contributor

GeorgNeis commented Jun 13, 2016

I guess this can be closed. I no longer think there is a bug.

@GeorgNeis GeorgNeis closed this Jun 13, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment