# ASI: Why are control flow statements and the postfix operator restricted?

**URL:** <https://es.discourse.group/t/asi-why-are-control-flow-statements-and-the-postfix-operator-restricted/1002>\
**Category:** I have questions\
**Created:** [September 28, 2021, 8:15am UTC](https://es.discourse.group/t/asi-why-are-control-flow-statements-and-the-postfix-operator-restricted/1002 "2021-09-28T08:15:46Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![monica](https://avatars.discourse-cdn.com/v4/letter/m/a183cd/32.png) [@monica](https://es.discourse.group/u/monica)\
**Post date:** [September 28, 2021, 8:15am UTC](https://es.discourse.group/t/asi-why-are-control-flow-statements-and-the-postfix-operator-restricted/1002/1 "2021-09-28T08:15:46Z")

</div>

I can see why `ArrowFunction` and `async`-related productions are restricted:

- For `ArrowFunction`, the restrictions are needed to resolve ambiguity with headless arrow functions (which was a [proposed feature](https://bterlson.github.io/headless-arrows/)).
- For `async`-related productions, the restrictions are needed to resolve ambiguity with `async` identifier references in code written prior to the introduction of the `async` keyword.

**Question:** _But there isn't any syntactic ambiguity in the case of control flow statements (`return`, `break`, `continue`, `yield` and `throw`) and postfix operators, so why are they restricted?_

The only justification I can think of is that someone who relies on ASI might write something like `if (condition) return \n function foo() {}` and _ **expect** _ ASI to insert a `;` after the `return` keyword. So the `[no LT here]` restriction might be needed to trigger ASI in such cases where there is an _ **expectation** _ of newline significance.

But I'm not sure if this is the reason given that ASI is an [error correction procedure](https://brendaneich.com/2012/04/the-infernal-semicolon/) and shouldn't be relied upon as a "universal significant-newline rule", i.e. the grammar isn't required to care about "expectations" of newline significance.

---

<div class="post-metadata">

**Author:** ![claudepache](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/claudepache/32/236_2.png) [@claudepache](https://es.discourse.group/u/claudepache)\
**Post date:** [September 28, 2021, 11:03am UTC](https://es.discourse.group/t/asi-why-are-control-flow-statements-and-the-postfix-operator-restricted/1002/2 "2021-09-28T11:03:58Z")

</div>

> [@monica](#):
>
> But I'm not sure if this is the reason given that ASI is an [error correction procedure](https://brendaneich.com/2012/04/the-infernal-semicolon/) and shouldn't be relied upon as a "universal significant-newline rule", i.e. the grammar isn't required to care about "expectations" of newline significance.

“Not required to care” doesn’t mean “should not care”. Since code is usually written by humans before being consumed by machines, it is perfectly reasonable for grammar to care about expectations.

(Also, as the expression of “error correction procedure” might be misinterpreted, it is worthwhile to note that [it is a technical term, not a moral one](https://brendaneich.com/2012/04/the-infernal-semicolon/#comment-1145).)

The case of `return` is here from the dawn of JS, at a time where ASI was thought as a worthwhile feature by the designer of the language. (Otherwise, there would have been no ASI, just flat syntax errors.) Therefore, he _did_ care about expectations.

For `break` and `continue`, it might be either by design, or for the sake of BC, (or both,) as [the two first editions of ECMAScript](https://www.ecma-international.org/publications-and-standards/standards/ecma-262/) did not include the form `break label;`, just `break;`, so that the following code did have an implicit semicolon after `break`:

```js
break
something;

```

My wild guess is that the cases of `throw` and `yield` are here for consistency with `return`. (Note that `yield` has appeared in SpiderMonkey long before it appeared in ECMAScript.)

The rule was not extended to `await`. (I think it was a minor error, and it should have been added for consistency, but this is just my opinion.) But this construct was added much later, and, in the meantime, the general feeling of language designers towards ASI had evolved.

---

<div class="post-metadata">

**Author:** ![monica](https://avatars.discourse-cdn.com/v4/letter/m/a183cd/32.png) [@monica](https://es.discourse.group/u/monica)\
**Post date:** [September 28, 2021, 1:23pm UTC](https://es.discourse.group/t/asi-why-are-control-flow-statements-and-the-postfix-operator-restricted/1002/3 "2021-09-28T13:23:55Z")

</div>

> [@claudepache](#):
>
> Also, as the expression of “error correction procedure” might be misinterpreted, it is worthwhile to note that [it is a technical term, not a moral one](https://brendaneich.com/2012/04/the-infernal-semicolon/#comment-1145).

Yes, I think I was misconstruing it as "user error" instead of "parsing error".

> [@claudepache](#):
>
> The case of `return` is here from the dawn of JS, at a time where ASI was thought as a worthwhile feature by the designer of the language. (Otherwise, there would have been no ASI, just flat syntax errors.) Therefore, he _did_ care about expectations.

That makes sense. Mr Eich talks about 'restricted productions' ([here](https://esdiscuss.org/topic/rationalizing-asi-was-simple-shorter-function-syntax#content-1)) and 'expectation of newline significance' ([here](https://esdiscuss.org/topic/automatic-semicolon-insertion-value-vs-cost-predictability-and-control-alternatives#content-45)). In the first link, he says:

> If we eliminate restricted productions by requiring semicolon after return, break, continue, throw [...], and postfix ++/--, is it better to go all the way and eliminate the syntactic error correction part of ASI?

...which seems to imply that the control flow / postfix restrictions are in place simply to satisfy the expectation of newline significance. Would you agree with my reading?

> [@claudepache](#):
>
> For `break` and `continue`, it might be either by design, or for the sake of BC, (or both,)

Good point about BC, I wouldn't have picked up on that.

Thank you for your help @claudepache. Also, I apologise if my post comes across as too pedantic. I personally don't rely on ASI but have still been bitten by the `return` restriction in the past, so it helps to understand where it's coming from.