tc39/proposal-export-default-from

[Q] Breaking change?

Opened this issue · 5 comments

nicolo-ribaudo commented

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

jdalton commented

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

benjamn commented

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.

  • 👍2
hax commented

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?"
  • 👍2
ExE-Boss commented

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

hax commented

@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.
  • 👍1