3 ms·

Aren't they optional 100% of the time though?

Waterluvian 5y ago
Not 100%. There are a small handful of really wicked gotchas. I think there’s a lot of articles on them. I can’t find the one I like and don’t want to share one I haven’t read yet.
- chrismorgan 5y ago
  Here’s an example in each direction. In this first example, ASI inserts an undesired semicolon: return {a: 0} This returns undefined, and doesn’t continue on to execute the block containing a statement 0 with label a. (Change it to {a: 0, b: 0} and you get a syntax error because of this reinterpretation of what was intended as an object literal.) In this second example, ASI doesn’t insert a desired semicolon: f() [].forEach.call(…) This becomes a syntax error, because the [] has become subscripting rather than an array literal. (Incidentally, [].forEach is smelly anyway; prefer Array.prototype.forEach, maybe assign that to a constant if you’re doing it much.)
  - runarberg 5y ago
    The second example could be replaced with something more common like: f() ['foo', 'bar'].forEach(...) Which is probably a type error, except if `f()` returns something like: function f() { return { bar: ['Not the array', 'you were expecting'], } } Then you would actually iterate over the returned `bar` array, not the expected `['foo', 'bar']` array. Another fairly likely example of a desired semicolon not inserted is when the following line starts with a template string literal: f() `This is tagged with whatever f() returns` This will most likely be a type error, except if `f()` returns a function, that function will then be called on the template string to do whatever. However I have a hard time imagining when you would want to start a statement with a template string literal without doing something smelly like: `some ${interpolated} string`.includes(someVar) ? sideEffectA() : sideEffectB()
- deleted 5y ago
  [deleted]

Not 100%. There are a small handful of really wicked gotchas. I think there’s a lot of articles on them. I can’t find the one I like and don’t want to share one I haven’t read yet.

chrismorgan 5y ago
Here’s an example in each direction. In this first example, ASI inserts an undesired semicolon: return {a: 0} This returns undefined, and doesn’t continue on to execute the block containing a statement 0 with label a. (Change it to {a: 0, b: 0} and you get a syntax error because of this reinterpretation of what was intended as an object literal.) In this second example, ASI doesn’t insert a desired semicolon: f() [].forEach.call(…) This becomes a syntax error, because the [] has become subscripting rather than an array literal. (Incidentally, [].forEach is smelly anyway; prefer Array.prototype.forEach, maybe assign that to a constant if you’re doing it much.)
- runarberg 5y ago
  The second example could be replaced with something more common like: f() ['foo', 'bar'].forEach(...) Which is probably a type error, except if `f()` returns something like: function f() { return { bar: ['Not the array', 'you were expecting'], } } Then you would actually iterate over the returned `bar` array, not the expected `['foo', 'bar']` array. Another fairly likely example of a desired semicolon not inserted is when the following line starts with a template string literal: f() `This is tagged with whatever f() returns` This will most likely be a type error, except if `f()` returns a function, that function will then be called on the template string to do whatever. However I have a hard time imagining when you would want to start a statement with a template string literal without doing something smelly like: `some ${interpolated} string`.includes(someVar) ? sideEffectA() : sideEffectB()
deleted 5y ago
[deleted]