HE Shi-Jun

I really support explicit keyword for local return of do expression. This also solve the trouble issue of refactoring IIFE with "early return" or ["guard pattern"](https://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html). The only question is...

@Pajn You could use `await` in async iife. About `break`, `continue`, `return`, though it could be see as the benefit, but it also have another side. Flow control were statements,...

Recent discussion at #34

There is a [section](https://github.com/tc39/proposal-export-default-from#compound-export-from-statements) in README, but not sure why `export v, * from 'mod'` was not mentioned.

> 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...

@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 ```js...

@MadProbe This issue already be listed in the docs (https://github.com/tc39/proposal-extensions/blob/master/docs/syntax.md#syntax-ambiguity-of-abc) though I'm sorry it not listed in the repo readme page. There are many possible solutions, `.:` may work, but...

First, only binary form need defining first, or `import ::{toArray} from ...`. The design goal is making extension (virtual) methods/properties behave as close as normal (real) methods/properties. The only difference...

Note, I understand it's not common to have separate namespace in JS, I'm still investigating the other options which mitigate the problem. One possibility is remove `const ::x = ...`...

Another point, if we really want applying method from a local binding directly, we could have syntax like `o::[foo]` or `o::(foo)`. Especially `o::(foo)` is somewhat compatible with the old proposal....