Skip to content
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

[Q] Breaking change? #2

Open
nicolo-ribaudo opened this issue Feb 9, 2018 · 5 comments
Open

[Q] Breaking change? #2

nicolo-ribaudo opened this issue Feb 9, 2018 · 5 comments
Labels

Comments

@nicolo-ribaudo
Copy link
Member

This proposal disallows export default from; (which is valid ES2017 code). Is it intentional?
Ref: babel/babel#7309

@jdalton
Copy link
Member

jdalton commented Feb 9, 2018

With from being a binding. That's a super cool find! \cc @benjamn

@benjamn
Copy link
Member

benjamn commented Feb 10, 2018

I think the decision to forbid export default from is a bug in the spec text, and in general I am opposed to introducing syntax gotchas like this one. Both of the other forbidden tokens are reserved words: function and class, so forbidding them has no drawback.

The only argument I can imagine for disallowing this production, despite the breaking change that it represents, is that the following syntaxes still work:

export { from as default }
export default (0, from)

Of course, that still leaves the objection that export default from was legal before/without this proposal.

Disambiguating export default from <any token other than a string literal> from export default from "module" just requires more lookahead, right?

Do newlines create a problem?

export default from
"just a string literal expression statement?"

This ambiguity is not fatal; we just need to decide what it means. My preference would be to avoid making newlines meaningful, so the above code would be a single export default from "module" declaration, rather than export default from followed by a string literal expression statement.

@hax
Copy link
Member

hax commented Oct 4, 2019

This ambiguity is not fatal; we just need to decide what it means. My preference would be to avoid making newlines meaningful, so the above code would be a single export default from "module" declaration, rather than export default from followed by a string literal expression statement.

No, you can't do that because it will change the semantic of current valid code, aka. breaking change.

The only option is keep treating it as

export default from // <-- ASI
"just a string literal expression statement?"

@ExE-Boss
Copy link
Contributor

ExE-Boss commented Oct 4, 2019

I wish JavaScript required semicolons, as that would’ve made many things unambiguous.

@hax
Copy link
Member

hax commented Oct 12, 2019

@ExE-Boss

  • We can't change the rules now. (Theoretically we could change some rules if no one rely on that, for example maybe there is no real code like
export default from
"string literal"

exist in the world...but who knows?

  • Even enforce semicolons there are still ambiguous in the language, for example:
return 
  {a: 1};

var exp;
do exp; // do expression proposal?
while (0) console.log('ok'); // ASI without line break!!
  • The problems are historical design decisions which cause ASI hazards or potential ASI hazards, not the design of optional semicolon itself. There are many other languages also use optional semicolon, but works fine.
  • (Controversially, but many programmers, include me, believe that) leading-semicolon coding style is easier and less error than semicolon-always coding style, especially in the situation that u do not have linter on the hand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants